Too many Recommends (in particular on mail-transport-agent)

[Ansgar Burchardt]

Hi,

my impression is that too many packages use Recommends that should
really be Suggests.  As a random example: installing dracut as a
initramfs provider will pull in exim4... (dracut-core Recommends: mdadm
which Recommends: default-mta | mail-transport-agent).  This seems
really not ideal.

As a result many people seem to disable installing recommended packages
by default.  I believe we should be much more agressive in downgrading
dependencies to Suggests.

For example, very few packages should Depend/Recommend a MTA: if you
just send notifications (like mdadm), you would need a properly
configured MTA anyway or they just end up in a file nobody will ever
look at (I don't see local mail to root as very useful).

I suggest that only very few packages should Recommend a MTA: packages
that mainly deal with mail on servers in some way or another (for
user-facing applications, speaking SMTP to a remote SMTP server is
common enough that these shouldn't Recommend a MTA usually either).

Ansgar

Bug#863719: ITP: gerbera -- UPnP Media Server

[James Cowgill]

Package: wnpp
Severity: wishlist
Owner: James Cowgill 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: gerbera
  Version : 1.0.0
  Upstream Author : Ian Whyman 
* URL : https://gerbera.io/
* License : GPL-2
  Programming Lang: C++
  Description : UPnP Media Server

Gerbera is a UPnP media server, originally based on MediaTomb, which
allows you to stream your digital media through your home network and
consume it on a variety of UPnP compatible devices.

This package is intended to replace MediaTomb which has been abandoned
upstream. I intend to package this as part of the Debian Multimedia  Team.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: Too many Recommends (in particular on mail-transport-agent)

[Jeremy Bicha]

On Tue, May 30, 2017 at 7:57 AM, Ansgar Burchardt  wrote:
> I suggest that only very few packages should Recommend a MTA: packages
> that mainly deal with mail on servers in some way or another (for
> user-facing applications, speaking SMTP to a remote SMTP server is
> common enough that these shouldn't Recommend a MTA usually either).

Ansgar, I see that you're an uploader for 'at'. What about the patches
I submitted at
https://bugs.debian.org/830950 ?

Thanks,
Jeremy Bicha

Re: Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[Ian Jackson]

David Kalnischkies writes ("Re: Bug#863361: dgit-user(7): replace apt-get 
build-deps with mk-build-deps"):
> I would recommend not to recommend it because apt follows the general
> recommendation of not recommending the installation of recommendations
> of build-dependencies by default for all recommended Debian releases.

When you install the build-depends for unfamiliar programs, you are
trying to debug, do you install recommends ?  I have found that it is
usually wiser not to.

Installing the recommends of build-depends typically shovels in
massive piles of junk, which is (a) a big download (b) often contains
daemons and other weirdness that is obviously not needed.

Ian.

Permanent transition tracker for Perl6 ? (was: Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...))

[Ian Jackson]

Dominique Dumont writes ("Permanent transition tracker for Perl6 ? (was: Re: 
Packaging of libraries with unstable ABI (D, Rust, Go, ...))"):
> On Thursday, 18 May 2017 16:37:58 CEST Matthias Klumpp wrote:
> > Unfortunately though, the D language ABI isn't stable, so any future
> > compiler update might break the software in weird ways unless all D
> > software is recompiled when a new compiler is released.
> 
> Perl6 has a similar issue: currently all modules (aka library) are pre-
> compiled ar run-time. The pre-compilation result is stored in user's home 
> directory ( ~/.perl6 ) to speed up the start-up time when a program is 
> launched.

~/.perl6 is a particularly annoying place to put this.  It defeats
the usual efforts to move this kind of thing to non-backed up storage,
or whatever.

> Unfortunately, these pre-compiled files are obsolete when a new Perl6 
> (rakudo) 
> compiler is released.

And does it automatically delete them, ever ?  If not then surely that
is a bug.

> All in all, I have three choices:
> 
> - ship only source in module and let rakudo install pre-compiled files. This 
> may require user to clean-up ~/.perl6 from time to time. This may cause 
> problems for daemon written in Perl6 (we're not there yet): e.g. how to clean 
> up ?

Quite.

> is letting daemon write its own pre-compiled file a security risk ?

Possibly, but the cache area should be by uid not by USER.

> - pre-compile all module are installation time (like python or emacs). The 
> main issues are: all modules must be re-compiled in the correct order when 
> rakudo is upgraded and how to clean up obsolete pre-compiled files. This 
> requires complex post-install scripts

Does Perl6 function correctly if these compiled files do not exist,
and cannot be written ?  If so you can do the compilation
opportunistically.  Python seems to take this approach.

> The latter is probably the best solution from my point of view. 
> 
> But a permanent tracker has an impact in the buildd: is this solution 
> acceptable ?

It seems rather poor.

Can you patch Perl6 to put the precompiled files alongside the
original source files, the way Python does it ?  Then you can reuse
the techniques used by the Python people, maybe.

Ian.

Re: Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[Emilio Pozuelo Monfort]

On 30/05/17 18:32, Ian Jackson wrote:
> David Kalnischkies writes ("Re: Bug#863361: dgit-user(7): replace apt-get 
> build-deps with mk-build-deps"):
>> I would recommend not to recommend it because apt follows the general
>> recommendation of not recommending the installation of recommendations
>> of build-dependencies by default for all recommended Debian releases.
> 
> When you install the build-depends for unfamiliar programs, you are
> trying to debug, do you install recommends ?  I have found that it is
> usually wiser not to.
> 
> Installing the recommends of build-depends typically shovels in
> massive piles of junk, which is (a) a big download (b) often contains
> daemons and other weirdness that is obviously not needed.

I think what David wanted to say is:

`apt-get install $foo' install recommends
`apt-get build-dep $foo' does not install recommends

Thus you don't need to pass --no-install-recommends when doing build-dep.

Cheers,
Emilio

Re: Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[Ian Jackson]

Emilio Pozuelo Monfort writes ("Re: Bug#863361: dgit-user(7): replace apt-get 
build-deps with mk-build-deps"):
> I think what David wanted to say is:
> 
> `apt-get install $foo' install recommends
> `apt-get build-dep $foo' does not install recommends
> 
> Thus you don't need to pass --no-install-recommends when doing build-dep.

Ah.  Has that changed ?  Certainly I have a finger macro to explicitly
disable the recommends for build deps but maybe it's not necessary...

Ian.

Re: Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[Adam Borowski]

On Tue, May 30, 2017 at 06:32:17PM +0100, Ian Jackson wrote:
> Emilio Pozuelo Monfort writes ("Re: Bug#863361: dgit-user(7): replace apt-get 
> build-deps with mk-build-deps"):
> > I think what David wanted to say is:
> > 
> > `apt-get install $foo' install recommends
> > `apt-get build-dep $foo' does not install recommends
> > 
> > Thus you don't need to pass --no-install-recommends when doing build-dep.
> 
> Ah.  Has that changed ?  Certainly I have a finger macro to explicitly
> disable the recommends for build deps but maybe it's not necessary...

#454479 and its dupe #467313.

-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.

Re: Mitigating the problem of limited security support

[Moritz Mühlenhoff]

Alberto Garcia wrote:
> The problem is that point releases with fixes for CVEs can also
> introduce regressions (#855103, introduced in 2.14.4). That one was
> fixed quickly, though, but that's why I was asking.

The security archive doesn't scale to play catchup with all those
rdeps. There's too many things missing in dak on security-master
to make that a viable option (and unfortunately development on
this is mostly stalled).

You're best technical bet would be to upgrade to new webkit releases in
stretch point releases, this would allow proper binNMUs and allow
people to testdrive via s-p-u. But that's up for the SRMs to
decide (and I doubt they want to deal with that kind of API
"stability" either).

Cheers,
Moritz

Re: Mitigating the problem of limited security support

[Jeremy Bicha]

On Tue, May 30, 2017 at 5:32 PM, Moritz Mühlenhoff  wrote:
> You're best technical bet would be to upgrade to new webkit releases in
> stretch point releases, this would allow proper binNMUs and allow
> people to testdrive via s-p-u. But that's up for the SRMs to
> decide (and I doubt they want to deal with that kind of API
> "stability" either).

That sounds like a good way to start.

I want webkit2gtk 2.16.3 in Debian 9.0. Does it just need a regular unblock bug?

Thanks,
Jeremy Bicha

Re: Too many Recommends (in particular on mail-transport-agent)

[Ben Caradoc-Davies]

On 30/05/17 23:57, Ansgar Burchardt wrote:

my impression is that too many packages use Recommends that should
really be Suggests.  As a random example: installing dracut as a
initramfs provider will pull in exim4... (dracut-core Recommends: mdadm
which Recommends: default-mta | mail-transport-agent).  This seems
really not ideal.


Trust is not transitive. Perhaps Recommends should not be either?

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Too many Recommends (in particular on mail-transport-agent)

[Anthony DeRobertis]

AFAIK, mdadm's default (and maybe only supported, without some custom 
scripting) way to report a degraded array is email. That's definitely an 
important feature as not noticing a degraded array will result in complete data 
loss (well, or at least restore from backup). 

OTOH, seems weird for Dracut to recommend mdadm. Surely a system booting from 
RAID would already have it installed? 

On May 30, 2017 7:57:03 AM EDT, Ansgar Burchardt  wrote:
>Hi,
>
>my impression is that too many packages use Recommends that should
>really be Suggests.  As a random example: installing dracut as a
>initramfs provider will pull in exim4... (dracut-core Recommends: mdadm
>which Recommends: default-mta | mail-transport-agent).  This seems
>really not ideal.
>
>As a result many people seem to disable installing recommended packages
>by default.  I believe we should be much more agressive in downgrading
>dependencies to Suggests.
>
>For example, very few packages should Depend/Recommend a MTA: if you
>just send notifications (like mdadm), you would need a properly
>configured MTA anyway or they just end up in a file nobody will ever
>look at (I don't see local mail to root as very useful).
>
>I suggest that only very few packages should Recommend a MTA: packages
>that mainly deal with mail on servers in some way or another (for
>user-facing applications, speaking SMTP to a remote SMTP server is
>common enough that these shouldn't Recommend a MTA usually either).
>
>Ansgar