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

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: 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

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

[Simon McVittie]

On Wed, 31 May 2017 at 00:20:18 +, Anthony DeRobertis wrote:
> AFAIK, mdadm's default (and maybe only supported, without some custom
> scripting) way to report a degraded array is email.

Can't it report this via the system log? (syslog, systemd-journald)

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

dracut defaults to creating a general-purpose initramfs that is not meant
to hard-code anything and can be used to boot "most" hardware (it gets the
root device from the kernel command-line, mounts the root, and reads the
rest of its configuration from there). If the necessary binaries for
modules like mdadm are not present, then they can't be included in the
generated initramfs, leaving it less general-purpose than it is intended
to be.

S

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

[Dmitrii Kashin]

Ben Caradoc-Davies  writes:

> Trust is not transitive.

If trust is not transitive, then what for trust network exists?

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

[Simon McVittie]

On Wed, 31 May 2017 at 11:32:29 +1200, Ben Caradoc-Davies wrote:
> Trust is not transitive. Perhaps Recommends should not be either?

Recommends are for the relationship "wanting foo but not bar is unusual".
If A Recommends B and B Recommends C, and if we assume for example
that "unusual" means 10% of users of A do not need B and 10% of users
of B do not need C, then installing Recommends means somewhere
between 0% and 20% of users of A get C unnecessarily. (The real figure
depends on whether not wanting B and not wanting C are positively or
negatively correlated, or independent.)

That still seems like it qualifies as "unusual" to me, so I think
Recommends are effectively transitive.

More practically, apt does not keep track of whether a package was
installed as a result of a recommendation, a hard dependency or user
request (the closest it gets is "automatically installed", but that
could be anywhere between Depends and Suggests), so non-transitive
Recommends are not currently implementable: when apt is upgrading B
and there is a new Recommends on C, apt does not know whether B
was installed due to a hard dependency or user request (in which
case you would say its Recommends on C should be respected),
or whether it was only installed because it was recommended by A
(in which case you would say the transitive Recommends on C should
be ignored).

S

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

[Adam Borowski]

On Wed, May 31, 2017 at 11:31:43AM +0100, Simon McVittie wrote:
> On Wed, 31 May 2017 at 11:32:29 +1200, Ben Caradoc-Davies wrote:
> > Trust is not transitive. Perhaps Recommends should not be either?
> 
> Recommends are for the relationship "wanting foo but not bar is unusual".
> If A Recommends B and B Recommends C, and if we assume for example
> that "unusual" means 10% of users of A do not need B and 10% of users
> of B do not need C, then installing Recommends means somewhere
> between 0% and 20% of users of A get C unnecessarily. (The real figure
> depends on whether not wanting B and not wanting C are positively or
> negatively correlated, or independent.)

That's true.

I'd say the biggest problem is maintainers having an emotional attachment to
their packages and thus overestimating their importance.

A random example (not meant to single out its maintainer):
libuuid1 (transitively essential) Recommends: uuid-runtime.
The latter is, as far as I understand, needed only if you generate a massive
number of uuids per seconds.  Packages that actually need so (like ceph)
actually Depend: uuid-runtime already.  The rest -- those which need a
single uuid per mkfs or so, are perfectly fine without that daemon.

Thus, axing this dependency or degrading it to Suggests would be probably a
good idea.  And there's hundreds if not thousands of Recommends of this kind
that need to be looked at -- this example is just more prominent as it
affects every Debian system.

(I'm not filing bugs yet as it's better to have a consensus first before
mass-filing.)

Meow!
-- 
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: Too many Recommends (in particular on mail-transport-agent)

[Henrique de Moraes Holschuh]

On Wed, 31 May 2017, Adam Borowski wrote:
> Thus, axing this dependency or degrading it to Suggests would be probably a
> good idea.  And there's hundreds if not thousands of Recommends of this kind
> that need to be looked at -- this example is just more prominent as it
> affects every Debian system.
> 
> (I'm not filing bugs yet as it's better to have a consensus first before
> mass-filing.)

It is being done on a per-case basis, isn't it?  Like you described the
libuid versus uuid-runtime?

So, it is not a mass-filing, and it is OK.  Just file the bugs one by
one, with your reasoning, and tag them with usertags if you want to
control them as an unit or something.

A mass-filing for this (the exact oposite of studying each recommends in
a case-by-case basis) _IS_ going to cause imense pushback.  I recommend
against it ;-)

-- 
  Henrique Holschuh

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

[Nicholas D Steeves]

On 30 May 2017 at 07:57, 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).

Maybe exim should easily provide or default to authenticated smarthost
(satellite) configuration and /etc/aliases should be configured to
forward system mail somewhere else (eg: the sysadmin's work email, in
case of SMART or md errors)?

Alternatively, if a real MTA is too heavy, why not install msmtp-mta
by default?  It (including msmtp) is only ~336K, and it's easy to set
up for authenticated SMTP.  Exim4-daemon-light is ~1292KB.  Maybe
these aren't easy enough to configure?  Does the following need to be
revisited?: https://wiki.debian.org/Debate/DefaultMTA

Are there people who wouldn't appreciate an email from smartd or md
warning them a hard drive is about to fail or that there is something
wrong with their array?  For desktops, it's way too easy to miss a
notification popup, assuming a notification system is installed...and
not all desktops have integrated smart monitoring, and not all users
install gsmartcontrol.  All users should receive notification of
hardware failure, no?  As I see it the issue is if an admin receives
uncountable apt-listchanges emails for something like when a great
many containers are upgraded, and it should be possible to skip
configuration (and disable) any provider of mail-transport-agent for
VMs and containers.

Cheers,
Nicholas

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

[Nicholas D Steeves]

On 31 May 2017 at 13:53, Adam Borowski  wrote:
> On Wed, May 31, 2017 at 11:31:43AM +0100, Simon McVittie wrote:
>> On Wed, 31 May 2017 at 11:32:29 +1200, Ben Caradoc-Davies wrote:
>> > Trust is not transitive. Perhaps Recommends should not be either?
>>
>> Recommends are for the relationship "wanting foo but not bar is unusual".
>> If A Recommends B and B Recommends C, and if we assume for example
>> that "unusual" means 10% of users of A do not need B and 10% of users
>> of B do not need C, then installing Recommends means somewhere
>> between 0% and 20% of users of A get C unnecessarily. (The real figure
>> depends on whether not wanting B and not wanting C are positively or
>> negatively correlated, or independent.)
>
> That's true.
>
> I'd say the biggest problem is maintainers having an emotional attachment to
> their packages and thus overestimating their importance.
>
> A random example (not meant to single out its maintainer):
> libuuid1 (transitively essential) Recommends: uuid-runtime.
> The latter is, as far as I understand, needed only if you generate a massive
> number of uuids per seconds.  Packages that actually need so (like ceph)
> actually Depend: uuid-runtime already.  The rest -- those which need a
> single uuid per mkfs or so, are perfectly fine without that daemon.
>
> Thus, axing this dependency or degrading it to Suggests would be probably a
> good idea.  And there's hundreds if not thousands of Recommends of this kind
> that need to be looked at -- this example is just more prominent as it
> affects every Debian system.
>
> (I'm not filing bugs yet as it's better to have a consensus first before
> mass-filing.)
>

With the exception of maintaining Recommends for mail-transport-agent
for packages where emailed warnings are highly desirable (there might
be others besides smartd and mdadm), I agree that there are many cases
were Recommends can be downgraded to Suggests.  My pet peeve is
unnecessary Recommends on texlive packages, but it's easy enough to
type "NO" and then install with --no-install-recommends...but if you
mass-file "please degrade Recommends to Suggests" I hope it will be
for a few of those :-)

Cheers,
Nicholas

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

[Adam Borowski]

On Wed, May 31, 2017 at 03:17:27PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 31 May 2017, Adam Borowski wrote:
> > (I'm not filing bugs yet as it's better to have a consensus first before
> > mass-filing.)
> 
> It is being done on a per-case basis, isn't it?  Like you described the
> libuid versus uuid-runtime?
> 
> So, it is not a mass-filing, and it is OK.  Just file the bugs one by
> one, with your reasoning, and tag them with usertags if you want to
> control them as an unit or something.
> 
> A mass-filing for this (the exact oposite of studying each recommends in
> a case-by-case basis) _IS_ going to cause imense pushback.  I recommend
> against it ;-)

I'd specifically want a kind of mass-filing: let's make a long list and
discuss it in a d-devel flamewar all at once, so we'd have some consistency.

Let's do it after Jun 18, though -- a bug filed today can't be acted on
immediately thus it'd be forgotten even if it's a single word change.

Applying an usertag would be useful, yeah, thanks for the reminder.

Meow!
-- 
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: Too many Recommends (in particular on mail-transport-agent)

[Luca Capello]

Hi there,

On Tue, 30 May 2017 13:57:03 +0200, Ansgar Burchardt wrote:
> 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).

AFAIK by default root is an alias for the first local user set up during
installation.  This at least was/is on the oldest Debian installation
upgraded and still running I have (and the same on jessie on my current
laptop) :
=
mantissa:/etc# git log -p 5deed858 aliases
commit 5deed8583b1a65e9f80a9426496c2e707ce6c860
Author: Luca Capello 
Date:   Thu Dec 31 15:11:07 2009 +0100

initial commit

diff --git a/aliases b/aliases
new file mode 100644
index 000..ba553bc
--- /dev/null
+++ b/aliases
@@ -0,0 +1,14 @@
[...]
+root: luca
mantissa:/etc# 
=

Given that local users are notified of new mail at a console login,
providing such notification at DE login would be a first step.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

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

[Vincent Danjean]

Le 31/05/2017 à 09:51, Simon McVittie a écrit :
> On Wed, 31 May 2017 at 00:20:18 +, Anthony DeRobertis wrote:
>> AFAIK, mdadm's default (and maybe only supported, without some custom
>> scripting) way to report a degraded array is email.
> 
> Can't it report this via the system log? (syslog, systemd-journald)

mdadm reported events are usually critical ones.
If I remember correctly, these events also appear in system log.
But, even if I use logcheck, it too easy to miss such events in
system logs (or logcheck reports) : there are too many events
(or too many false positives for logcheck).

mails from mdadm are really an very important feature for me.

  Regards,
 Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

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

[Anthony DeRobertis]

On May 31, 2017 3:51:33 AM EDT, Simon McVittie  wrote:
>On Wed, 31 May 2017 at 00:20:18 +, Anthony DeRobertis wrote:
>> AFAIK, mdadm's default (and maybe only supported, without some custom
>> scripting) way to report a degraded array is email.
>
>Can't it report this via the system log? (syslog, systemd-journald)

The kernel already does, but of course the system log has a lot of messages, 
every several seconds on some systems. And the systemd journal can be even 
worse, volume-wise. 

Logs are great for figuring out what happened after the fact, but what it needs 
is an alert. Immediate action must be taken, data is at risk. 

It would be great it we had an alert program to use instead of email (and that 
program would make sure the user/admin is aware via persistent desktop alert, 
email, whatever). I think it's been discussed before... If we had one, it'd be 
relatively easy to have mdadm, smartmontools, etc. use it. 

>
>> OTOH, seems weird for Dracut to recommend mdadm. Surely a system
>> booting from RAID would already have it installed?
>
>dracut defaults to creating a general-purpose initramfs that is not
>meant
>to hard-code anything and can be used to boot "most" hardware 

I'm not really familiar with Dracut, but I'll note that needing mdadm is almost 
always a property of the OS install being booted, not of the hardware it's 
running on. So not including mdadm doesn't make the particular install any less 
portable, though it does make the initramfs less general to booting arbitrary 
installs.

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

[Anthony DeRobertis]

On May 31, 2017 2:38:51 PM EDT, Nicholas D Steeves  wrote:

>
>Maybe exim should easily provide or default to authenticated smarthost
>(satellite) configuration and /etc/aliases should be configured to
>forward system mail somewhere else (eg: the sysadmin's work email, in
>case of SMART or md errors)?

I believe exim used to ask, via debconf, the user to configure email and that 
was one of the options (not sure if the debconf prompts would set up 
authentication for you, or if you had to edit one trial format config file as 
well). But the priority of those questions was lowered so now by default you're 
left without configured email.

That did reduce the number of questions asked for the default install—a 
worthwhile goal, I think. 

I don't think there is any way to configure mail to go to a non-local sysadmin 
email account without asking questions, unfortunately. Some of those questions 
are going to be confusing ("what is a smarthost? Sender rewriting?") or 
problematic (if you're installing on your primary computer, do you have email 
username and password readily available? what if it's Gmail, and you now need 
to go set up an app-specific password, or turn on SMTP? Hard to do from the 
installer.) 

Once you've got the system up, though, dpkg-reconfigure -plow exim4-config 
ought to get it set up. 

PS: there have been many discussions about changing the default MTA or dumping 
it all together on -devel.

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

[Simon McVittie]

On Thu, 01 Jun 2017 at 07:43:49 +, Anthony DeRobertis wrote:
> On May 31, 2017 3:51:33 AM EDT, Simon McVittie  wrote:
> >dracut defaults to creating a general-purpose initramfs that is not
> >meant
> >to hard-code anything and can be used to boot "most" hardware 
> 
> I'm not really familiar with Dracut, but I'll note that needing mdadm
> is almost always a property of the OS install being booted, not of the
> hardware it's running on.

Right, what I meant is that a dracut initramfs is meant to be usable
to boot most *systems* (whether differentiated by hardware or OS
configuration).

S

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

[Ghislain Vaillant]

On Wed, 2017-05-31 at 14:41 -0400, Nicholas D Steeves wrote:
> On 31 May 2017 at 13:53, Adam Borowski  wrote:
> > On Wed, May 31, 2017 at 11:31:43AM +0100, Simon McVittie wrote:
> > > On Wed, 31 May 2017 at 11:32:29 +1200, Ben Caradoc-Davies wrote:
> > > > Trust is not transitive. Perhaps Recommends should not be either?
> > > 
> > > Recommends are for the relationship "wanting foo but not bar is unusual".
> > > If A Recommends B and B Recommends C, and if we assume for example
> > > that "unusual" means 10% of users of A do not need B and 10% of users
> > > of B do not need C, then installing Recommends means somewhere
> > > between 0% and 20% of users of A get C unnecessarily. (The real figure
> > > depends on whether not wanting B and not wanting C are positively or
> > > negatively correlated, or independent.)
> > 
> > That's true.
> > 
> > I'd say the biggest problem is maintainers having an emotional attachment to
> > their packages and thus overestimating their importance.
> > 
> > A random example (not meant to single out its maintainer):
> > libuuid1 (transitively essential) Recommends: uuid-runtime.
> > The latter is, as far as I understand, needed only if you generate a massive
> > number of uuids per seconds.  Packages that actually need so (like ceph)
> > actually Depend: uuid-runtime already.  The rest -- those which need a
> > single uuid per mkfs or so, are perfectly fine without that daemon.
> > 
> > Thus, axing this dependency or degrading it to Suggests would be probably a
> > good idea.  And there's hundreds if not thousands of Recommends of this kind
> > that need to be looked at -- this example is just more prominent as it
> > affects every Debian system.
> > 
> > (I'm not filing bugs yet as it's better to have a consensus first before
> > mass-filing.)
> > 
> 
> With the exception of maintaining Recommends for mail-transport-agent
> for packages where emailed warnings are highly desirable (there might
> be others besides smartd and mdadm), I agree that there are many cases
> were Recommends can be downgraded to Suggests.  My pet peeve is
> unnecessary Recommends on texlive packages, but it's easy enough to
> type "NO" and then install with --no-install-recommends...but if you
> mass-file "please degrade Recommends to Suggests" I hope it will be
> for a few of those :-)

+1 on the texlive packages.

Considering their definitions in d-policy:

```
Recommends:

This declares a strong, but not absolute, dependency. The Recommends
field should list packages that would be found together with this one
in all but unusual installations.

Suggests:

This is used to declare that one package may be more useful with one or
more others. Using this field tells the packaging system and the user
that the listed packages are related to this one and can perhaps
enhance its usefulness, but that installing this one without them is
perfectly reasonable.
```

I fail to understand how -doc packages can qualify for anything else
but Suggests.

Ghis

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

[Henrique de Moraes Holschuh]

On Thu, 01 Jun 2017, Anthony DeRobertis wrote:
> On May 31, 2017 3:51:33 AM EDT, Simon McVittie 
>  wrote:
> >Can't it report this via the system log? (syslog, systemd-journald)
> 
> The kernel already does, but of course the system log has a lot of
> messages, every several seconds on some systems. And the systemd
> journal can be even worse, volume-wise. 

The kernel log, syslog, and the journal... all of them have the idea of
message priorities.

Anything on the top three priorities (critical, alert and emergency) is
supposed to be displayed immediately to all logged-in users (including
remote ones), no matter what.

> It would be great it we had an alert program to use instead of email

KDE displays high-priority system alerts as high priority notifications
by default (maybe some of it because of the default configuration of
rsyslog).

rsyslog will forcefully write high-priority messages to all ttys, local
and remote, by default.

If your DE doesn't display system alerts by default, it is a fight you
might want to take... file bugs!

> discussed before... If we had one, it'd be relatively easy to have
> mdadm, smartmontools, etc. use it. 

We have had this working for the better part of two decades, through
syslog.  We also have had an extremely good daemon to take care of it
for nearly half that time: rsyslog.  And rsyslog is configured to do the
right thing by default.

Since journald can plug to syslog just fine, and does so by default in
Debian, it also does the right thing by default at least in Debian.

What we *might* not do by default is to force all the DEs to display
these alerts out-of-the-box.  I haven't tested all main DEs for this, so
I wouldn't know.

> >> OTOH, seems weird for Dracut to recommend mdadm. Surely a system
> >> booting from RAID would already have it installed?
> >
> >dracut defaults to creating a general-purpose initramfs that is not
> >meant to hard-code anything and can be used to boot "most" hardware 
> 
> I'm not really familiar with Dracut, but I'll note that needing mdadm
> is almost always a property of the OS install being booted, not of the
> hardware it's running on. So not including mdadm doesn't make the
> particular install any less portable, though it does make the
> initramfs less general to booting arbitrary installs.

Correct.

The initramfs-tools does not depend or recommend mdadm.  However,
initramfs-tools is modular and its mdadm support is supplied by the
mdadm package.

Dracut isn't modular, and its mdadm support is built-in.  This is a key
difference.

One needs to actually read dracut's source code to know how it would
behave in all boundary conditions related to mdadm support, in which
case it might only suggest or not even mention mdadm.  It probably is
safe, but the point is that someone has to check it first.

-- 
  Henrique Holschuh

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

[Alessandro Vesely]

On Wed 31/May/2017 23:28:58 +0200 Vincent Danjean wrote:
> Le 31/05/2017 à 09:51, Simon McVittie a écrit :
>> On Wed, 31 May 2017 at 00:20:18 +, Anthony DeRobertis wrote:
>>> AFAIK, mdadm's default (and maybe only supported, without some custom
>>> scripting) way to report a degraded array is email.
>> 
>> Can't it report this via the system log? (syslog, systemd-journald)
> 
> mdadm reported events are usually critical ones.
> [...]
> 
> mails from mdadm are really an very important feature for me.

It is enough to have an email client.  Of course, an SMTP server, which also
provides relaying through a local mail queue, provides client capabilities as a
bonus.  Yet, a simpler command-line SMTP client, e.g. msmtp, can be configured
more easily than a full-blown MTA.

Ale

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

[Anthony DeRobertis]

On 06/01/2017 01:00 PM, Henrique de Moraes Holschuh wrote:


Anything on the top three priorities (critical, alert and emergency) is
supposed to be displayed immediately to all logged-in users (including
remote ones), no matter what.


Only LOG_EMERG does that, at least on my machine and I'm pretty sure 
that's the default rsyslog config. Unfortunately, a RAID member failure 
is only legitimately LOG_ALERT. Sort of a moot point though...





It would be great it we had an alert program to use instead of email

KDE displays high-priority system alerts as high priority notifications
by default (maybe some of it because of the default configuration of
rsyslog).


Running KDE here, so familiar with them. The first problem with those is 
they automatically vanish after a few seconds. They remain around, if 
you pull up the alert notifier, but that little (1) in the systray is 
easy to miss.


Second problem is that only works if you're logged in. Even on a typical 
desktop where the main user is the admin, it's not safe to assume a that 
user will always be logged in:


 * Turn on machine, go grab coffee or tea while it's booting. Disk
   failure occurs before you get back and log in.
 * Log out for the night, but leave it on for e.g. backups, file
   serving, or remote access
 * Log out so your kids can use the machine

Third problem, syslog imposes some pretty severe format restrictions on 
the message. An alert sent via email can have a lot more details & 
instructions than a syslog message.


Using a machine as a home media server (e.g., a NAS) is a reasonably 
common thing too—then it'll hardly ever have a local logged in user.


You can surely configure rsyslog to get that alert to you anyway. 
(Probably using ommail!). But that's no easier than configuring outgoing 
email.

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

[Henrique de Moraes Holschuh]

On Fri, 02 Jun 2017, Anthony DeRobertis wrote:
> On 06/01/2017 01:00 PM, Henrique de Moraes Holschuh wrote:
> >Anything on the top three priorities (critical, alert and emergency) is
> >supposed to be displayed immediately to all logged-in users (including
> >remote ones), no matter what.
> 
> Only LOG_EMERG does that, at least on my machine and I'm pretty sure that's
> the default rsyslog config. Unfortunately, a RAID member failure is only
> legitimately LOG_ALERT. Sort of a moot point though...

Hmm, true.  I misrecalled this detail and failed to check it to be
correct before posting.

We should consider changing that to at least include ALERT as well.

> >>It would be great it we had an alert program to use instead of email
> >KDE displays high-priority system alerts as high priority notifications
> >by default (maybe some of it because of the default configuration of
> >rsyslog).
> 
> Running KDE here, so familiar with them. The first problem with those is
> they automatically vanish after a few seconds. They remain around, if you
> pull up the alert notifier, but that little (1) in the systray is easy to
> miss.

Yes.  I just tested it in Debian stable with "logger -p EMERG
this_is_only_a_test".

It would be far better if KDE used the (!) pictogram at least for ALERT
and EMERG priorities, but it seems to be getting the messages from the
ttys instead of from journald or the syslog daemon.  I did not test this
throughoutly, though.

And yes, I stand corrected. It does not display ALERT or CRIT priorities
by default, only EMERG.  Which is Not Good Enough as far as I am
concerned.

> Second problem is that only works if you're logged in. Even on a typical
> desktop where the main user is the admin, it's not safe to assume a that
> user will always be logged in:

Well, yes.  Remote syslog (wherever deployed) will receive the messages
quasi-real-time, though.  And the messages *are* going to be recorded on
the journal and /var/log/syslog.

Whether someone will read the logs or not, well... it is the same issue
with notifications over local email to root: one has to assume the
system has been properly configured as an Unix workstation (and thus it
has local email routing that goes somewhere it will be read).

I am for doing the three by default: email (for stuff like mdadm),
proper syslog or journald (for everything), and proper desktop-
environment notifications for whomever is logged in.

>  * Turn on machine, go grab coffee or tea while it's booting. Disk
>failure occurs before you get back and log in.

In the older days, you'd have the messages on the login tty, even if it
screwed up the graphical screen (Solaris and Sun-OS style ;p).

Or you'd have a xconsole window open, even on the xdm screen (which I
never tried to do, I wonder if this was a local xdm change...)

-- 
  Henrique Holschuh

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

[Julian Andres Klode]

On Tue, May 30, 2017 at 01:57:03PM +0200, 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).

I'm wondering if we should give the user more control over Recommends
or Suggests, either by having some kind of blacklist in APT, or introducing
some form of profiles, like build profiles.

Then you could say: By default, do not install .*-doc$ recommends or
do not install recommends in the doc profile. Or do install suggests
in the foobar profile.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

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

[Afif Elghraoui]

على الثلاثاء 30 أيار 2017 ‫07:57، كتب Ansgar Burchardt:
> 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.

I completely agree. I've teken issue with packages recommending packages
in the spirit of "if you want this, you might also want X", which is the
literal sense of the word "recommends", but fits the definition in
policy for Suggests ("package may be more useful with one or more
others"). I've been unsuccessful in arguing this case before (#849619),
so I don't think the bug-filing method previously suggested [1] will
work. I think there needs to be a clarification to everyone of what
Recommends is for, since there seem to be different interpretations
(although the policy looks quite clear to me).

I see this as a real problem for cases where a Recommends is actually
important. As an example, I have a package pbhoney that Recommends
pbdagcon. If pbdagcon is not installed, pbhoney has a fallback
implementation that is not as good. So it is highly preferable to have
pbdagcon installed if it is available, but you can still use pbhoney
without it--although it will not run as well. I see that this perfectly
fits the definition of Recoomends ("a strong, but not absolute,
dependency"). but if people go on and globally use
--no-install-recommends, there may be an unnecessarily negative
consequence here.


regards
Afif

1. https://lists.debian.org/debian-devel/2016/04/msg00159.html

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

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

[Tom H]

On Thu, Jun 1, 2017 at 1:00 PM, Henrique de Moraes Holschuh
 wrote:
>
> The initramfs-tools does not depend or recommend mdadm. However,
> initramfs-tools is modular and its mdadm support is supplied by the
> mdadm package.
>
> Dracut isn't modular, and its mdadm support is built-in. This is a key
> difference.
>
> One needs to actually read dracut's source code to know how it would
> behave in all boundary conditions related to mdadm support, in which
> case it might only suggest or not even mention mdadm. It probably is
> safe, but the point is that someone has to check it first.

If mdadm isn't available, dracut'll print a warning along the lines of
"mdadm will not be installed".

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

[Ian Jackson]

Afif Elghraoui writes ("Re: Too many Recommends (in particular on 
mail-transport-agent)"):
> I completely agree. I've teken issue with packages recommending packages
> in the spirit of "if you want this, you might also want X", which is the
> literal sense of the word "recommends", but fits the definition in
> policy for Suggests ("package may be more useful with one or more
> others"). I've been unsuccessful in arguing this case before (#849619),
> so I don't think the bug-filing method previously suggested [1] will
> work. I think there needs to be a clarification to everyone of what
> Recommends is for, since there seem to be different interpretations
> (although the policy looks quite clear to me).

I think we should take a test case or two to the Technical Committee.

Before doing that, it would be wise to try to find the answer to the
key question which the TC will ask.  Suppose A recommends B.  In what
way, or in what circumstances, will A fail due to lack of B ?

In #849619 I don't see the answer to that question.

Ian.

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

[Jeremy Bicha]

On Mon, Jun 5, 2017 at 8:43 AM, Ian Jackson
 wrote:
> Before doing that, it would be wise to try to find the answer to the
> key question which the TC will ask.  Suppose A recommends B.  In what
> way, or in what circumstances, will A fail due to lack of B ?
>
> In #849619 I don't see the answer to that question.

On the other hand, to someone who doesn't know much about those
packages, I don't see anything in that bug to explain why it's a
problem for those other packages to be installed.

By the way, if a package "fails", that sounds like a Depends
relationship is needed not a Recommends.

Thanks,
Jeremy Bicha

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

[Ian Jackson]

Jeremy Bicha writes ("Re: Too many Recommends (in particular on 
mail-transport-agent)"):
> On Mon, Jun 5, 2017 at 8:43 AM, Ian Jackson
>  wrote:
> > Before doing that, it would be wise to try to find the answer to the
> > key question which the TC will ask.  Suppose A recommends B.  In what
> > way, or in what circumstances, will A fail due to lack of B ?
> >
> > In #849619 I don't see the answer to that question.
> 
> On the other hand, to someone who doesn't know much about those
> packages, I don't see anything in that bug to explain why it's a
> problem for those other packages to be installed.

This thread is about the problem of Recommends bloat.  This bloat
wastes download time and disk space; and it unnecessarily exposes
users to additional risks (of brokenness, and sometimes of security
problems etc.).

It is not usually appropriate to respond to a question "why is this
Recommends" with "why is it a problem for this package to be
installed".

> By the way, if a package "fails", that sounds like a Depends
> relationship is needed not a Recommends.

No.  Even if A usually fails without B, Recommends is more appropriate
than Depends if there are plausible ways to use A without B.


It does seem that some maintainers are unclear on these principles, or
their application; despite what seems to me to be very clear wording
in policy.  So I think we need some examples.  To work well they
should have a high profile and be authoritative, so that means taking
a couple of contested cases to the TC.  Maybe #849619 would make a
good test case.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

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

[Jeremy Bicha]

On Mon, Jun 5, 2017 at 9:15 AM, Ian Jackson
 wrote:
> It does seem that some maintainers are unclear on these principles, or
> their application; despite what seems to me to be very clear wording
> in policy.  So I think we need some examples.  To work well they
> should have a high profile and be authoritative, so that means taking
> a couple of contested cases to the TC.  Maybe #849619 would make a
> good test case.

Respectfully, #849619 is not at all a very convincing test case yet.

Thanks,
Jeremy Bicha

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

[Ian Jackson]

Jeremy Bicha writes ("Re: Too many Recommends (in particular on 
mail-transport-agent)"):
> On Mon, Jun 5, 2017 at 9:15 AM, Ian Jackson
>  wrote:
> > It does seem that some maintainers are unclear on these principles, or
> > their application; despite what seems to me to be very clear wording
> > in policy.  So I think we need some examples.  To work well they
> > should have a high profile and be authoritative, so that means taking
> > a couple of contested cases to the TC.  Maybe #849619 would make a
> > good test case.
> 
> Respectfully, #849619 is not at all a very convincing test case yet.

That's why I wrote, earlier:

  > Before doing that, it would be wise to try to find the answer to the
  > key question which the TC will ask.  Suppose A recommends B.  In what
  > way, or in what circumstances, will A fail due to lack of B ?
  >
  > In #849619 I don't see the answer to that question.

The answer to that is not clear from the maintainer's response; nor is
it clear from what the submitter has written whether they know the
answer.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

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

[Jeremy Bicha]

On Mon, Jun 5, 2017 at 9:42 AM, Ian Jackson
 wrote:
> Jeremy Bicha writes ("Re: Too many Recommends (in particular on 
> mail-transport-agent)"):
>> Respectfully, #849619 is not at all a very convincing test case yet.
>
> That's why I wrote, earlier:

I think you're looking at this from the opposite perspective that I
am. If you intent to ask the TC to override a Debian maintainer, I
think your arguments need to be much more detailed and documented on
the bug why you believe it to be that critical of an issue.

Thanks,
Jeremy Bicha

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

[Scott Kitterman]

On Monday, June 05, 2017 02:42:37 PM Ian Jackson wrote:
> Jeremy Bicha writes ("Re: Too many Recommends (in particular on mail-
transport-agent)"):
> > On Mon, Jun 5, 2017 at 9:15 AM, Ian Jackson
> > 
> >  wrote:
> > > It does seem that some maintainers are unclear on these principles, or
> > > their application; despite what seems to me to be very clear wording
> > > in policy.  So I think we need some examples.  To work well they
> > > should have a high profile and be authoritative, so that means taking
> > > a couple of contested cases to the TC.  Maybe #849619 would make a
> > > good test case.
> > 
> > Respectfully, #849619 is not at all a very convincing test case yet.
> 
> That's why I wrote, earlier:
>   > Before doing that, it would be wise to try to find the answer to the
>   > key question which the TC will ask.  Suppose A recommends B.  In what
>   > way, or in what circumstances, will A fail due to lack of B ?
>   > 
>   > In #849619 I don't see the answer to that question.
> 
> The answer to that is not clear from the maintainer's response; nor is
> it clear from what the submitter has written whether they know the
> answer.

Why is that question relevant?  The policy definition of Recommends (versus 
Suggests) has nothing to with if there will be a failure or not:

> The Recommends field should list packages that would be found together with
> this one in all but unusual installations

Personally, I think the maintainer articulated what he views as the usual 
situation and declines to remove Recommends that are, in the maintainer's 
view, appropriate.  His rationale makes complete sense to me.  I'm not saying 
there aren't other, reasonable choices that could be made, but it make sense.  
I don't think this is the kind of thing the TC should even entertain 
overruling a maintainer on.

For things like this, get consensus on a new definition for Recommends first 
as this looks to me to be well within the scope of the current definition.  
Not even close.

Scott K



signature.asc
Description: This is a digitally signed message part.

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

[Ian Jackson]

Jeremy Bicha writes ("Re: Too many Recommends (in particular on 
mail-transport-agent)"):
> I think you're looking at this from the opposite perspective that I
> am. If you intent to ask the TC to override a Debian maintainer, I
> think your arguments need to be much more detailed and documented on
> the bug why you believe it to be that critical of an issue.

Recommends bloat as a whole is a serious problem for the whole
project.  This is true even though the problem caused by each
individual instance is small.

Our second-line institutional structures (after individual
maintainers) for dealing with _classes_ of problem are policy (which
is already very clear IMO on this, but is often not followed);
automation (lintian, buildds, rebuild tests, etc); and peer review
(d-devel); and ftpmaster review (not applicable to existing packages
and I don't think they focus on this).

Unfortunately Recommends abuse is too subjective to be readily
amenable to the latter.  (Although perhaps a better information system
showing the causes of bloat might help.)  Peer review seems often to
fail on this point; and that is because the way to approach the
abstract rules seems to be disputed.

That means we need to go to our third-line response.  I think that's
the TC.  Getting the TC to add its voice to the abstract imprecations
is not helpful.  On the other hand I a good worked example or two
would help educate maintainers, and strengthen the power of peer
review.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

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

[Ian Jackson]

Ian Jackson writes ("Re: Too many Recommends (in particular on 
mail-transport-agent)"):
> Jeremy Bicha writes ("Re: Too many Recommends (in particular on 
> mail-transport-agent)"):
> > I think you're looking at this from the opposite perspective that I
> > am. If you intent to ask the TC to override a Debian maintainer, I
> > think your arguments need to be much more detailed and documented on
> > the bug why you believe it to be that critical of an issue.
> 
> Recommends bloat as a whole is a serious problem for the whole
> project.  This is true even though the problem caused by each
> individual instance is small.
> 
> Our second-line institutional structures (after individual
> maintainers) for dealing with _classes_ of problem are policy (which
> is already very clear IMO on this, but is often not followed);
> automation (lintian, buildds, rebuild tests, etc); and peer review
> (d-devel); and ftpmaster review (not applicable to existing packages
> and I don't think they focus on this).
> 
> Unfortunately Recommends abuse is too subjective to be readily
> amenable to the latter.
   to automated assessment.

Ian.

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

[Holger Levsen]

On Mon, Jun 05, 2017 at 03:03:08PM +0100, Ian Jackson wrote:
> Recommends bloat as a whole is a serious problem for the whole
> project. 

I disagree.
 
Both from my personal POV as well as from the feedback I get from Debian
users. There are many things in Debian being complained about, "recommends
bloat" is not among them.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

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

[Russ Allbery]

Terry McKenna  writes:

> Regarding "bloat"

>> I think we should take a test case or two to the Technical Committee.

> This one may be at the extreme, but it is one I personally encountered. I
> was installing nmap on a system (no gui) and was a bit shocked.  The
> problem is well articulated by one post (an my thanks to him for the work
> around).

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714320#17

Given that this was fixed, I'm not sure this is a great example of Debian
not dealing with this problem?

>> So I looked around in the dependency tree a little, and the eventual
>> cause is that liblinear1 recommends liblinear-tools,

lothlorien:~$ apt-cache show liblinear3 | grep liblinear-tools
Suggests: liblinear-tools (= 2.1.0+dfsg-2), liblinear-dev (= 2.1.0+dfsg-2)

>> which in turn recommends libsvm-tools,

lothlorien:~$ apt-cache show liblinear-tools | grep libsvm-tools
Suggests: libsvm-tools

It's ongoing work to track down these sorts of Recommends and get rid of
unexpected or unintended consequences, and there probably will always be
bugs.  What I'm missing, as a reader of the thread, is some indication
that this is a comprehensive problem that involves a significant conflict
of opinions that needs to be escalated.

Maybe someone has a list of things they view as Recommends inflation that
have (a) been reported as bugs to the appropriate package maintainers, and
(b) have been rejected by those package maintainers?  Those are the
controversial ones that we'd need to talk about.

The ones where, once someone tells them, the package maintainer goes "oh,
whoops" and changes the dependency aren't a problem.  They're Debian
working as it should.

-- 
Russ Allbery (r...@debian.org)   

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

[Afif Elghraoui]

على الإثنين  5 حزيران 2017 ‫08:43، كتب Ian Jackson:
> 
> I think we should take a test case or two to the Technical Committee.
> 
> Before doing that, it would be wise to try to find the answer to the
> key question which the TC will ask.  Suppose A recommends B.  In what
> way, or in what circumstances, will A fail due to lack of B ?
> 
> In #849619 I don't see the answer to that question.
> 

I see now that python-networkx has some integration with those
visualization libraries [1], which is not what I expected to be the
case, though the page also says:

~~~
NetworkX provides basic functionality for visualizing graphs, but its
main goal is to enable graph analysis rather than perform graph
visualization. In the future, graph visualization functionality may be
removed from NetworkX or only available as an add-on package.
~~~

so I guess until that integration is removed, it makes sense to keep it
as Recommends. My main problem remains, however, and it is that networkx
brings in a graphics stack when you try to install pbhoney on a headless
machine, like cluster compute nodes. See in an unstable chroot:


# apt-get install pbhoney
Reading package lists... Done
Building dependency tree
...
The following NEW packages will be installed:
  blasr blt ca-certificates dbus file fontconfig fontconfig-config
fonts-liberation fonts-lyx
  gnome-icon-theme graphviz gtk-update-icon-cache hicolor-icon-theme
javascript-common
  krb5-locales libaec0 libann0 libatk1.0-0 libatk1.0-data
libavahi-client3 libavahi-common-data
  libavahi-common3 libblas-common libblas3 libblasr libbsd0 libcairo2
libcdt5 libcgraph6
  libcroco3 libcups2 libcurl3-gnutls libdatrie1 libdbus-1-3 libexpat1
libexpat1-dev libffi6
  libfontconfig1 libfreetype6 libgail-common libgail18 libgd3
libgdk-pixbuf2.0-0
  libgdk-pixbuf2.0-common libgfortran3 libglade2-0 libglib2.0-0
libglib2.0-data libgnutls30
  libgraphite2-3 libgssapi-krb5-2 libgtk2.0-0 libgtk2.0-bin
libgtk2.0-common libgts-0.7-5
  libgts-bin libgvc6 libgvpr2 libharfbuzz0b libhdf5-100 libhdf5-cpp-100
libhogweed4 libhts1
  libice6 libicu57 libidn2-0 libjbig0 libjpeg62-turbo libjs-jquery
libjs-jquery-ui libk5crypto3
  libkeyutils1 libkrb5-3 libkrb5support0 liblapack3 liblcms2-2
libldap-2.4-2 libldap-common
  libltdl7 libmagic-mgc libmagic1 libnettle6 libnghttp2-14 libp11-kit0
libpango-1.0-0
  libpangocairo-1.0-0 libpangoft2-1.0-0 libpathplan4 libpbbam libpbdata
libpbihdf libpbseq
  libpixman-1-0 libpng16-16 libpsl5 libpython-dev libpython-stdlib
libpython2.7 libpython2.7-dev
  libpython2.7-minimal libpython2.7-stdlib librsvg2-2 librsvg2-common
librtmp1 libsasl2-2
  libsasl2-modules libsasl2-modules-db libsm6 libssh2-1 libssl1.1 libsz2
libtasn1-6 libtcl8.6
  libthai-data libthai0 libtiff5 libtk8.6 libunistring0 libwebp6
libwebpdemux2 libwebpmux2
  libx11-6 libx11-data libxau6 libxaw7 libxcb-render0 libxcb-shm0
libxcb1 libxcomposite1
  libxcursor1 libxdamage1 libxdmcp6 libxdot4 libxext6 libxfixes3 libxft2
libxi6 libxinerama1
  libxml2 libxmu6 libxpm4 libxrandr2 libxrender1 libxss1 libxt6
libyaml-0-2 mime-support openssl
  pbdagcon pbhoney pbjelly publicsuffix python python-cairo
python-cycler python-dateutil
  python-decorator python-dev python-functools32 python-glade2
python-gobject-2 python-gtk2
  python-h5py python-imaging python-intervaltree python-intervaltree-bio
python-matplotlib
  python-matplotlib-data python-minimal python-networkx python-numpy
python-pbbanana
  python-pbsuite-utils python-pil python-pkg-resources python-pygraphviz
python-pyparsing
  python-pysam python-scipy python-six python-sortedcontainers
python-subprocess32 python-tk
  python-tz python-yaml python2.7 python2.7-dev python2.7-minimal
samtools sgml-base
  shared-mime-info tk8.6-blt2.5 ttf-bitstream-vera ucf x11-common
xdg-user-dirs xml-core
0 upgraded, 197 newly installed, 0 to remove and 0 not upgraded.
Need to get 98.7 MB/120 MB of archives.
After this operation, 361 MB of additional disk space will be used.


and without recommends:

The following NEW packages will be installed:
  blasr libaec0 libblas-common libblas3 libblasr libcurl3-gnutls
libexpat1 libffi6 libgfortran3
  libgnutls30 libgssapi-krb5-2 libhdf5-100 libhdf5-cpp-100 libhogweed4
libhts1 libidn2-0
  libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 liblapack3
libldap-2.4-2 libldap-common
  libnettle6 libnghttp2-14 libp11-kit0 libpbbam libpbdata libpbihdf
libpbseq libpsl5
  libpython-stdlib libpython2.7-minimal libpython2.7-stdlib librtmp1
libsasl2-2
  libsasl2-modules-db libssh2-1 libssl1.1 libsz2 libtasn1-6
libunistring0 mime-support pbhoney
  pbjelly python python-decorator python-h5py python-intervaltree
python-intervaltree-bio
  python-minimal python-networkx python-numpy python-pbbanana
python-pbsuite-utils python-pysam
  python-six python-sortedcontainers python2.7 python2.7-minimal samtools
0 upgraded, 61 newly installed, 0 to remove and 0 not upgraded.
Need to get 15.0 MB/23.8 MB of archives.
After this operation, 86.6 MB of additional disk 

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

[Ghislain Vaillant]

On Tue, 2017-06-06 at 00:14 -0400, Afif Elghraoui wrote:
> I see now that python-networkx has some integration with those
> visualization libraries [1], which is not what I expected to be the
> case, though the page also says:
> 
> ~~~
> NetworkX provides basic functionality for visualizing graphs, but its
> main goal is to enable graph analysis rather than perform graph
> visualization. In the future, graph visualization functionality may be
> removed from NetworkX or only available as an add-on package.
> ~~~
> 
> so I guess until that integration is removed, it makes sense to keep it
> as Recommends. My main problem remains, however, and it is that networkx
> brings in a graphics stack when you try to install pbhoney on a headless
> machine, like cluster compute nodes.

Given this is a Python package, we should not even have to argue about
package relationships. Setuptools metadata provides install_requires
and extras_require, the former mapping to Depends, the latter to
Suggests. Period.

Your typical Python project README would instruct users to install the
Python package via `pip install`. If one runs `pip install networkx`,
the graphics dependencies do not get pulled. That alone is enough to
justify that these dependencies should not go to Recommends.

FYI, I have a similar problem with sympy (#861741), which pulls an
insane amount of packages via chained Recommends.

Ghis

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

[Jonas Smedegaard]

Quoting Ghislain Vaillant (2017-06-06 10:13:55)
> On Tue, 2017-06-06 at 00:14 -0400, Afif Elghraoui wrote:
>> I see now that python-networkx has some integration with those 
>> visualization libraries [1], which is not what I expected to be the 
>> case, though the page also says:
>>
>> ~~~
>> NetworkX provides basic functionality for visualizing graphs, but its 
>> main goal is to enable graph analysis rather than perform graph 
>> visualization. In the future, graph visualization functionality may 
>> be removed from NetworkX or only available as an add-on package.
>> ~~~
>>
>> so I guess until that integration is removed, it makes sense to keep 
>> it as Recommends. My main problem remains, however, and it is that 
>> networkx brings in a graphics stack when you try to install pbhoney 
>> on a headless machine, like cluster compute nodes.
>
> Given this is a Python package, we should not even have to argue about 
> package relationships. Setuptools metadata provides install_requires 
> and extras_require, the former mapping to Depends, the latter to 
> Suggests. Period.
>
> Your typical Python project README would instruct users to install the 
> Python package via `pip install`. If one runs `pip install networkx`, 
> the graphics dependencies do not get pulled. That alone is enough to 
> justify that these dependencies should not go to Recommends.
>
> FYI, I have a similar problem with sympy (#861741), which pulls an 
> insane amount of packages via chained Recommends.

We should certainly continue to align package relations with Debian 
Policy - and therefore by extension continue to argue about that as 
necessary to evolve Debian Policy:

Upstream (or other) package relation hints can be a valuable _aid_ in 
resolving Debian package relations, but only that: An aid!

Debian packaging follows Debian Policy - other hints do not.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

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

[Adam Borowski]

On Mon, Jun 05, 2017 at 05:39:41PM -0700, Russ Allbery wrote:
> Maybe someone has a list of things they view as Recommends inflation that
> have (a) been reported as bugs to the appropriate package maintainers, and
> (b) have been rejected by those package maintainers?  Those are the
> controversial ones that we'd need to talk about.

Here's something even better: an automated way to list bad Recommends that
personally affect you -- ones that made you take steps to ignore them when
installing a package you actually use:

.--==[ list-unsatisfied-recommends ]
#!/usr/bin/python
import apt
c = apt.Cache()
for pkg in c:
if pkg.installed is not None:
for rd in pkg.candidate.get_dependencies("Recommends"):
if not rd.installed_target_versions:
print pkg, rd
`

Forgot whom to credit for this tool; alas, it's written in a language that
itself is bloat[1].

More seriously, though, let's go through the list of 94 unsatisfied ones on
my desktop; the list below is transposed to collate recommendees.


Categories:
OK: "Recommends:" looks warranted
DEBATABLE: duh.
BLOAT: potentially useful but I wouldn't make it a Recommends
BAD: downgrade please
TRANSITIVELY BAD: useful for a direct user but not when pulled via a
dependency -or- causes this lower in the chain



alpine-doc: alpine
* OK: this one looks reasonable

at: devscripts
* BAD: only use: pts-{,un}subscribe.  Why would I ever be interested in a
  package for only a limited time?  The listed use case is bad: NMUs are
  done on unmaintained packages, thus they won't magically fix themselves in
  30 days.

bash-completion: bash dput-ng licensecheck
* DEBATABLE: I like the Tab key to do something reasonable,
  "bash-completion" means you never know what you'll get.

: libreoffice-base
* BLOAT: they're no longer owned by Sun, what's the reason to keep Java
  scripting?

dnsmasq-base: lxc
* BAD: how often are you on a network without a DNS server?

fonts-cantarell: fontforge-common
* BAD: FontForge works perfectly without it

fonts-noto-cjk: fonts-noto
* BLOAT: unlike greek/runes/etc, you can't learn Chinese hieroglyphs on a
  whim, thus it's useless for most users.  You may want a _single_ CJK font
  so you can tell whether a text is in C, J or K but that's it.

freedoom | game-data-packager: prboom-plus
* DEBATABLE: freedoom is too ugly to live, shareware Doom has assets missing
  for running pretty much anything Doom-related (and AFAIK its license
  forbids add-ons).  On the other hand, this is an excuse for Doom engines
  in main.

freepats: libwildmidi-config timidity
* BAD: freepats is too ugly to live: abysmal quality, lacks instruments for
  pretty much any .mid file in the wild.  We do have a bunch of good
  alternatives.  timgm6mb-soundfont for one is 5.6 times smaller yet is
  complete.

geoclue-2.0: redshift
* TRANSITIVELY BAD: insane dependency chains, otherwise would be useful for
  a mobile device (this desktop is not one)

gfortran-mingw-w64: gcc-mingw-w64
* BAD: seriously, Fortran?

ghostscript: gimp imagemagick-6.q16 libmagickcore-6.q16-3 netpbm
* BAD: why would editing images care about a grossly obsolete _document_
  format?

gimp-gmic: gimp-plugin-registry
* BLOAT: an obscure plugin, looks useful for only for a small minority of
  users; -plugin-registry is not pulled by default though so it's debatable

gnat-mingw-w64: gcc-mingw-w64
* BAD: see Fortran.

gnupg-l10n: gnupg
* DEBATABLE: I don't think anyone tech skilled enough to use GPG would have
  problems with English, but localization is important.  On the other hand,
  this is 4.5MB in the default install.

gsfonts: libmagickcore-6.q16-3 libwmf0.2-7
* BAD: see ghostscript

gvfs: atril easytag thunar
* BAD: gvfs is a major annoyance and a security hole

libaacs0: libbluray1
* BLOAT: useful only if you rip optical media

libatm1 >= 2.4.1-17~: iproute2
* BLOAT: I'm rather certain my desktop machine has no direct ATM link --
  unfit for the default install

libclass-xsaccessor-perl: libmoo-perl
* BLOAT: wut?

libgit-wrapper-perl: devscripts
* : I've never used git-deborig, is it actually useful?  Tiny package,
  though.

libgnomeui-0: xscreensaver
* BAD: Gnome users won't run xscreensaver

libgpm2: libncurses5:i386
* OK: or rather, not doable with current tools: we do want mouse support
  in curses programs (libgpm2 handles X terminals too, right?) but in this
  case it's a multiarch copy of an otherwise important package

libgpod-common: libgpod4
* BLOAT: nope, I don't use iJunk

libgtk2-perl: tablet-encode
* out of archive

libhtml-format-perl: libhtml-tree-perl libwww-perl
* : wut?

libhttp-daemon-perl: libwww-perl
* TRANSITIVELY BAD: dependency comes from a client package; if I want to run
  a http server I know where to find it

libimage-magick-perl: inkscape
* : wut?

liblist-compare-perl: devscripts
* : again, git-deborig

libmail-sendmail-perl: po-debconf
* BAD: why would po stuff want to send mail?

libpackage-stash-xs-perl: lib

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

[Jonas Smedegaard]

Quoting Adam Borowski (2017-06-06 15:55:48)
> More seriously, though, let's go through the list of 94 unsatisfied 
> ones on my desktop; the list below is transposed to collate 
> recommendees.
> 
> 
> Categories:
> OK: "Recommends:" looks warranted
> DEBATABLE: duh.
> BLOAT: potentially useful but I wouldn't make it a Recommends
> BAD: downgrade please
> TRANSITIVELY BAD: useful for a direct user but not when pulled via a
> dependency -or- causes this lower in the chain
> 
> 
> 
> bash-completion: bash dput-ng licensecheck
> * DEBATABLE: I like the Tab key to do something reasonable,
>   "bash-completion" means you never know what you'll get.

I don't understand what is debatable here.  Please consider filing a 
bugreport against licensecheck to start that debate (if not here).


> fonts-noto-cjk: fonts-noto
> * BLOAT: unlike greek/runes/etc, you can't learn Chinese hieroglyphs on a
>   whim, thus it's useless for most users.  You may want a _single_ CJK font
>   so you can tell whether a text is in C, J or K but that's it.

The very purpose of Noto fonts is large coverage (no "tofu" chars), and 
the very purpose of "fonts-noto" package specifically is described as 
"Use this package if you want all Noto fonts".  If you disagree with 
that, then avoid fonts-noto altogether, don't try redefine its prupose.


> ghostscript: gimp imagemagick-6.q16 libmagickcore-6.q16-3 netpbm
> * BAD: why would editing images care about a grossly obsolete _document_
>   format?

Because some (most except you, I guess!) don't consider PDF "obsolete".


> gnupg-l10n: gnupg
> * DEBATABLE: I don't think anyone tech skilled enough to use GPG would have
>   problems with English, but localization is important.  On the other hand,
>   this is 4.5MB in the default install.

We should not actively make GnuPG _harder_ for newcomers to use.


> libclass-xsaccessor-perl: libmoo-perl
> * BLOAT: wut?

This and other lib*-xs-perl recommendations are faster implementations 
that you commonly want: An example (exotic!) need for avoiding those is 
when bootstrapping a new architecture.



 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

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

[Russ Allbery]

Adam Borowski  writes:

> More seriously, though, let's go through the list of 94 unsatisfied ones
> on my desktop; the list below is transposed to collate recommendees.

And what happens here is, I think, typical: any one person often thinks
choices of recommends make no sense, but a broader perspective provides
quite a bit of justification.  A good example:

> dnsmasq-base: lxc
> * BAD: how often are you on a network without a DNS server?

Your question here indicates to me that you've missed the point of this
dependency entirely.  lxc uses the dnsmasq program (not service, hence
-base) for *DHCP* for containers on the container network.  If you do a
search for lxc dnsmasq, you'll see tons of justification for this
Recommends.  lxc is already pulling in tons of stuff; it would be dumb to
make it harder to use by omitting this small recommends of a few binaries.

> gsfonts: libmagickcore-6.q16-3 libwmf0.2-7
> * BAD: see ghostscript

Your concept of what file formats are obsolete is not even remotely
similar to mine.

> libgnomeui-0: xscreensaver
> * BAD: Gnome users won't run xscreensaver

What?  The hell they won't.

> libmail-sendmail-perl: po-debconf
> * BAD: why would po stuff want to send mail?

This is for podebconf-report-po.  I assume you've not packaged something
with translations?

> libpam-systemd: xfce4-power-manager xfce4-session
> * BAD: Depends:systemd, utterly pointless without it.

This is a whole other discussion, but we had *endless* discussions of
this, and there are very sound technical reasons for structuring the
dependency chain this way.

> libpurple-bin: libpurple0
> * BAD: a library has no reason to install programs

This, like all other lib*-bin packages in Debian, are external helper
utilities *run by the library* under specific situations, which are split
into a separate package to avoid SONAME issues.  This is an entirely
correct packaging strategy for optional library APIs (in this case, things
like opening remote URLs).

I'm going to stop here, since at this point I think this is just going to
turn into a thread educating you about Debian packaging conventions you've
apparently not encountered before, which is really not a good use of
everyone's time.

I am completely unconvinced that there is any real problem here.  There
are doubtless some bugs, most of them minor, in our separation between
Recommends and Suggests, and there's probably some opportunity to craft
better language to guide packagers to do the right thing, but mostly
there's an opportunity for people to file a few bugs after a *thoughtful*
analysis of package Recommends and why they might be there.  There
certainly doesn't seem to be a problem large enough to warrant TC
involvement.

-- 
Russ Allbery (r...@debian.org)   

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

[Simon McVittie]

On Tue, 06 Jun 2017 at 09:06:46 -0700, Russ Allbery wrote:
> Adam Borowski  writes:
> > More seriously, though, let's go through the list of 94 unsatisfied ones
> > on my desktop; the list below is transposed to collate recommendees.
> 
> And what happens here is, I think, typical: any one person often thinks
> choices of recommends make no sense, but a broader perspective provides
> quite a bit of justification.

Adam, if you want the size of a typical system to be reduced, I don't
think the approach you've taken here is going to be the most effective.
Making maintainers angry by dismissing software as obsolete, pointless or
similar - even if it is true! - is not usually going to make them more
likely to do what you say.

I can see that you value minimal systems. That's fine, but bear in mind
that you are experienced enough to make those systems work, and
hopefully also experienced enough to avoid making them insecure while
making them work; and relately, you are experienced enough to use a
package manager to get the system the way you want it. Not everyone is.

If there is a best set of Recommends for inexperienced users, and a
best set of Recommends for experienced users who value minimality, then
we should err in the direction of supporting the inexperienced users,
precisely because those are the people least likely to be able to use
package managers to get a particular feature that they want. If some
"wasted" disk space on typical systems is the price we pay for a feature
working on the first attempt, rather than an inexperienced user giving
up before they can get that feature to work, or simply not knowing that
the feature is even possible, then that seems a worthwhile price to pay.

You are already making a cost/benefit trade-off by using Debian, a
relatively complete binary distribution. You could get a more minimal
system by disabling more things at compile time with something like
Gentoo's USE flags, but presumably you've considered that and decided
that the benefits of using a binary distribution outweigh the costs.

(Insert the usual observation here about how a typical Debian system
has both libapparmor and libselinux, despite it being literally
impossible for both to be useful at the same time...)

> > libgnomeui-0: xscreensaver
> > * BAD: Gnome users won't run xscreensaver
> 
> What?  The hell they won't.

This one *is* obsolete though - not xscreensaver, but libgnomeui-0.
libgnome and libgnomeui were deprecated sometime during the GNOME 2
era, and for stretch the GNOME team has finally managed to exclude them
from a default desktop installation (task-gnome-desktop), but
unfortunately there are still more than 50 packages using them.
The GNOME team would be delighted to see that number go down.
The libgnome* libraries help you to integrate with a desktop from around
10 years ago that we no longer ship, and are not part of modern GNOME;
their high-level functionality has mostly been superseded by code in
GLib and GTK+.

During the time that libgnome was a recommended thing to use,
I think xscreensaver was used by default in a complete GNOME
installation. It was subsequently replaced by gnome-screensaver,
which was in turn replaced by the screen lock included in GNOME Shell
during the transition to GNOME 3. It is certainly possible to construct
your own GNOME-based desktop environment that includes xscreensaver by
fitting together the pieces yourself (similar to how the openbox-*-session
packages provide openbox-based variants of several desktop environments),
but that isn't the complete GNOME environment any more than
openbox-gnome-session is.

S

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

[Tom H]

On Tue, Jun 6, 2017 at 9:55 AM, Adam Borowski  wrote:
>
> dnsmasq-base: lxc
> * BAD: how often are you on a network without a DNS server?

The dnsmasq-base "recommends" is about providing a dhcp server for
containers not a dns server.

libvirt-daemon-system has the same "recommends" for its VMs.

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

[Russ Allbery]

Simon McVittie  writes:

> If there is a best set of Recommends for inexperienced users, and a
> best set of Recommends for experienced users who value minimality, then
> we should err in the direction of supporting the inexperienced users,
> precisely because those are the people least likely to be able to use
> package managers to get a particular feature that they want.

Yes, this.  Experienced users can also turn off installation of
Recommends, so I think the focus should be on making things work "as
expected" for people who don't want to understand the details.

There's also a huge difference, given this criteria, betweeen wasted disk
space and running daemons.  I think the latter is worth trying to track
down; the former seems largely futile to me.  All of the disk space gains
you might conceivably get from, say, removing the recommeds on
libmail-sendmail-perl from po-debconf will be dwarfed by minor changes to
the documentation of some other package on your system, or some new
feature in some standard library.

> If some "wasted" disk space on typical systems is the price we pay for a
> feature working on the first attempt, rather than an inexperienced user
> giving up before they can get that feature to work, or simply not
> knowing that the feature is even possible, then that seems a worthwhile
> price to pay.

Amen.

>>> libgnomeui-0: xscreensaver
>>> * BAD: Gnome users won't run xscreensaver

>> What?  The hell they won't.

> This one *is* obsolete though - not xscreensaver, but libgnomeui-0.
> libgnome and libgnomeui were deprecated sometime during the GNOME 2 era,
> and for stretch the GNOME team has finally managed to exclude them from
> a default desktop installation (task-gnome-desktop), but unfortunately
> there are still more than 50 packages using them.  The GNOME team would
> be delighted to see that number go down.  The libgnome* libraries help
> you to integrate with a desktop from around 10 years ago that we no
> longer ship, and are not part of modern GNOME; their high-level
> functionality has mostly been superseded by code in GLib and GTK+.

Ah, good call.  So this one really should be a bug report.

https://bugs.debian.org/864310 -- please feel free to weigh in and correct
me if I got any of the details wrong.

-- 
Russ Allbery (r...@debian.org)   

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

[Adam Borowski]

On Tue, Jun 06, 2017 at 09:06:46AM -0700, Russ Allbery wrote:
> Adam Borowski  writes:
> 
> > More seriously, though, let's go through the list of 94 unsatisfied ones
> > on my desktop; the list below is transposed to collate recommendees.
> 
> And what happens here is, I think, typical: any one person often thinks
> choices of recommends make no sense, but a broader perspective provides
> quite a bit of justification.

It is remarkable that out of 94 unsatisfied recommends on my system you
disagreed with just 6, despite them going contrary to the maintainer's
wishes thus being certain to be controversial.

Also, it's quite obvious this list was very hastily done, with often just a
few seconds per entry.  Thus, I admit the list does contain inaccuracies
that fail when confronted with a bit more research.  The intent is just to
have a sample -- not to file actual bugs yet.

> A good example:
> 
> > dnsmasq-base: lxc
> > * BAD: how often are you on a network without a DNS server?
> 
> Your question here indicates to me that you've missed the point of this
> dependency entirely.  lxc uses the dnsmasq program (not service, hence
> -base) for *DHCP* for containers on the container network.

I do use lxc quite heavily, usually choosing IP addresses within config
files but sometimes using DHCP.  And it seems to work just fine without
dnsmasq -- thus, unless I'm missing something, it's not something that
"would be found together [...] in all but unusual installations".

> If you do a search for lxc dnsmasq, you'll see tons of justification for
> this Recommends.  lxc is already pulling in tons of stuff; it would be
> dumb to make it harder to use by omitting this small recommends of a few
> binaries.

906kB is bigger than most of Recommends on this list, but as not a part of
the default install you do have a point that it may make it easier to have
pre-installed: while it's a common setup to store a lxc host on a separate
small filesystem, typical lxc boxes aren't on the small side overall.
I'm not persuaded about the importance of this add-on, but that's exactly
why we're having this debate.

The point of a debate is not to "win" but to find the best solution...

> > gsfonts: libmagickcore-6.q16-3 libwmf0.2-7
> > * BAD: see ghostscript
> 
> Your concept of what file formats are obsolete is not even remotely
> similar to mine.

I did not happen to know ghostscript can also be used not for .ps but also
for some .pdf workflows (I prefer to not use blatantly fake-free software)
but my main point stands: an _image_ manipulation program cannot be said to
import _documents_ in "all but unusual installations".

And "gsfonts" is not even ghostscript itself but merely an add-on for it.

> > libgnomeui-0: xscreensaver
> > * BAD: Gnome users won't run xscreensaver
> 
> What?  The hell they won't.

There's gnome-screensaver, which has better integration with Gnome at the
cost of using a ton of gnome-related bloat (which doesn't hurt a Gnome user
in any way -- they already have that installed).  Thus, a _typical_ Gnome
user won't install xscreensaver, and a typical xscreensaver user won't
install Gnome.  And "Recommends:" is all about typical use.

Plus, as Simon McVittie mentioned, libgnomeui-0 is strongly deprecated even
within Gnome itself.

> > libmail-sendmail-perl: po-debconf
> > * BAD: why would po stuff want to send mail?
> 
> This is for podebconf-report-po.  I assume you've not packaged something
> with translations?

I'm not dealing with any po-heavy packages at the moment, yeah.  It might
indeed be useful for some deep po stuff, but the package I want is
"debhelper".  Technically, I do know how to package without debhelper (see
"goodbye") but I still would prefer to use it.  And as someone involved in
both QA and sponsoring -- thus dealing with hundreds of packages -- I have
yet to use podebconf-report-po once.  Thus, it's quite hard to say that
debhelper and libmail-sendmail-perl "would be found together in all but
unusual installations".

> > libpam-systemd: xfce4-power-manager xfce4-session
> > * BAD: Depends:systemd, utterly pointless without it.
> 
> This is a whole other discussion, but we had *endless* discussions of
> this, and there are very sound technical reasons for structuring the
> dependency chain this way.

Let's not waste too much time right now, but if I recall that discussion
correctly, the sane way would be to have a non-systemd alternative _first_:
on a systemd install, the second alternative would be already present and
thus satisfy the dependency, while the first one would avoid imposing
systemd when not wanted.

> > libpurple-bin: libpurple0
> > * BAD: a library has no reason to install programs
> 
> This, like all other lib*-bin packages in Debian, are external helper
> utilities *run by the library* under specific situations, which are split
> into a separate package to avoid SONAME issues.

Nope, its contents are four misc "extra utilities" that are mean to run _by
the user_ or at most by

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

[Russ Allbery]

Adam Borowski  writes:
> On Tue, Jun 06, 2017 at 09:06:46AM -0700, Russ Allbery wrote:

>> And what happens here is, I think, typical: any one person often thinks
>> choices of recommends make no sense, but a broader perspective provides
>> quite a bit of justification.

> It is remarkable that out of 94 unsatisfied recommends on my system you
> disagreed with just 6, despite them going contrary to the maintainer's
> wishes thus being certain to be controversial.

I skipped all of the ones that you didn't mark as BAD, since the other
classifications were beside the point, and commented only on the ones
where your classification leaped out at me as incorrect.  I'm pretty
dubious about the whole list, but as I said at the start of my message, I
was giving some specific examples where I had the information readily to
hand (or thought I did; I was wrong on libpurple).

> Also, it's quite obvious this list was very hastily done, with often
> just a few seconds per entry.

And you did this in response to a message of mine that was asking for
something more thoughtful, which is part of why I reacted the way that I
did.

> I did not happen to know ghostscript can also be used not for .ps but
> also for some .pdf workflows (I prefer to not use blatantly fake-free
> software) but my main point stands: an _image_ manipulation program
> cannot be said to import _documents_ in "all but unusual installations".

> And "gsfonts" is not even ghostscript itself but merely an add-on for it.

PostScript is one of the common image types (in the form of EPS) that
ImageMagick manipulates.  Use of ImageMagick to handle those files is not
as common as JPEG or PNG, but certainly not unusual, particularly if you
have tool chains that like to generate EPS; I used to run into it a lot
when processing TeX documents, for instance.  gsfonts may be a requirement
for correctly converting some of those files to other formats because it
provides the fonts that are "built in to any PostScript printer" and
therefore do not have to be embedded in files (by specification).

This is pretty classic Recommends stuff, just in a field that you're not
personally using ImageMagick for.  One can argue about the merits of
having a Swiss Army knife tool like ImageMagick that is pretty much
guaranteed to only be used for 10% of what it can do by any given user of
it, but in that context, support for PostScript images is well within its
scope and less obscure than many other formats it handles.

>>> libmail-sendmail-perl: po-debconf
>>> * BAD: why would po stuff want to send mail?

>> This is for podebconf-report-po.  I assume you've not packaged something
>> with translations?

> I'm not dealing with any po-heavy packages at the moment, yeah.  It
> might indeed be useful for some deep po stuff, but the package I want is
> "debhelper".

podebconf-report-po is not "deep po stuff."  It should be used by
literally every maintainer who packages something with debconf
translations, whenever the debconf templates are changed.

> Technically, I do know how to package without debhelper (see "goodbye")
> but I still would prefer to use it.

po-debconf includes the tools the package maintainer should be using to
manage debconf translations.  You could conceivably separate the ones
needed during a build from the maintainer tools, but I'm not sure it's
really worth the effort for the tiny amount of disk space this would save.

>> This, like all other lib*-bin packages in Debian, are external helper
>> utilities *run by the library* under specific situations, which are split
>> into a separate package to avoid SONAME issues.

> Nope, its contents are four misc "extra utilities" that are mean to run
> _by the user_ or at most by some scripts.  They look somewhat useful
> (purple-remote allows controlling pidgin from cmdline, etc) but are
> seriously hampered by a lack of documentation.  On the other hand, not a
> single one is ever called by the library:

> strings `dpkg -L libpurple0`|grep purple-remote
> strings `dpkg -L libpurple0`|grep purple-send
> strings `dpkg -L libpurple0`|grep purple-send-async
> strings `dpkg -L libpurple0`|grep purple-url-handler

Ah, indeed, I apologize; you're entirely correct.  I made a bad assumption
about how the URL handling in libpurple worked and should have done a
little bit of research first.

I think (barring other information I'm not aware of) I agree with you
here, and also think that the name of this package is probably wrong and
should be something more like purple-tools or the like.

>> I'm going to stop here, since at this point I think this is just going
>> to turn into a thread educating you about Debian packaging conventions
>> you've apparently not encountered before, which is really not a good
>> use of everyone's time.

> Uhm... could you be please be a bit more civil?

I apologize; you're right.  I should have been more civil.

I do have to also add that I found your message considerably less civil
than how I think you

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

[Philip Hands]

Adam Borowski  writes:

>> > dnsmasq-base: lxc
>> > * BAD: how often are you on a network without a DNS server?
>> 
>> Your question here indicates to me that you've missed the point of this
>> dependency entirely.  lxc uses the dnsmasq program (not service, hence
>> -base) for *DHCP* for containers on the container network.
>
> I do use lxc quite heavily, usually choosing IP addresses within config
> files but sometimes using DHCP.  And it seems to work just fine without
> dnsmasq -- thus, unless I'm missing something, it's not something that
> "would be found together [...] in all but unusual installations".

I suspect that you are bridging your containers straight onto a real
network, which is then providing the DHCP, whereas the default
arangement for naive users is to have a layer of NAT or some such (I'm
not 100% sure, because like you I never use that option either, but I'm
aware it exists).

I also suspect that if you have configured lxc as you have, dnsmasq sits
unused on the disk, which is not something to object to if it means that
people using the default setup get something that works -- which they
would not get if you had your way.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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

[Adam Borowski]

On Tue, Jun 06, 2017 at 01:06:03PM -0700, Russ Allbery wrote:
> Adam Borowski  writes:
> > Uhm... could you be please be a bit more civil?
> 
> I apologize; you're right.  I should have been more civil.
> 
> I do have to also add that I found your message considerably less civil
> than how I think you actually intended it.  I found your message rather
> condescending and dismissive of the analysis maintainers have put into
> their package metadata, and confrontational about your personal opinions
> about some widely used software, in a way that felt honestly like you were
> intentionally provoking people.

Indeed, I was once again wise-ass where I should be wise[1] -- at least some
of the remarks were condescending when read literally.  My bad.

> > The issue is systematic, and we have far more than "a few" cases.  The
> > very post you're responding to had 94 of them,
> 
> There were absolutely not 94 real problems on that list.  It was a largely
> unfiltered dump of Recommends of packages on your system.  I would be
> surprised if there were more than 10 real problems there, most of which
> are quite minor in terms of user impact and didn't seem to be to be worth
> the amount of energy that you're putting into this.

I do disagree here, but I'll better pause talking in this thread to let the
heat down.  And, bugs filed today would be forgotten -- while it takes
almost no effort to make a single-word change, once you context switch away
it becomes a part of the backlog and ignored.

> That said, I absolutely welcome bug reports against any of my packages for
> too-broad Recommends

I went through your packages (57 sources, 251 binaries), and found no
issues (I only skimmed through nvidia stuff, though).  So if I'm going to
bark at anyone, it's not at you. :)

> And if there's wording we can change on the Policy side to try to make it
> clearer when Recommends should be used and to head off some of these
> issues

Let's see what other folks have to say.



Meow!

[1]. Although pabs is taken.
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄ nearly two years of no catch!)

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

[Michael Biebl]

Am 06.06.2017 um 18:06 schrieb Russ Allbery:
> Adam Borowski  writes:

>> libpam-systemd: xfce4-power-manager xfce4-session
>> * BAD: Depends:systemd, utterly pointless without it.
> 
> This is a whole other discussion, but we had *endless* discussions of
> this, and there are very sound technical reasons for structuring the
> dependency chain this way.

xfce4-power-manager, xfc4-session recommending libpam-systemd (or even
requiring libpam-systemd) seems correct, as those use systemd-logind.

The Recommends systemd-sysv | systemd-shim is superfluous and should be
dropped. It's an implementation detail whether systemd (PID 1) or
systemd-shim provides the functionality needed by
libpam-systemd/systemd-logind.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Michael Biebl]

Am 06.06.2017 um 15:55 schrieb Adam Borowski:
> gvfs: atril easytag thunar
> * BAD: gvfs is a major annoyance and a security hole

"Annoys Adam Borowski" is not a very convincing argument.
As for "security hole", I'm not sure what exactly you have in mind
there. I don't see any open CVEs or bugs tagged with security against gvfs.


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[Adam Borowski]

On Tue, Jun 06, 2017 at 11:29:20PM +0200, Michael Biebl wrote:
> Am 06.06.2017 um 15:55 schrieb Adam Borowski:
> > gvfs: atril easytag thunar
> > * BAD: gvfs is a major annoyance and a security hole
> 
> "Annoys Adam Borowski" is not a very convincing argument.

For the first part, it indeed varies by use case.  I don't recall ever using
an USB or SD attached storage for "data" in an Unix machine, yet I have two
SD readers, four cards and one USB stick on my desk right now despite having
cleaned the desk a few days ago.  It's just always a "disk" for some SoC
or bootable media (d-i, etc).

Some people may disagree.

> As for "security hole", I'm not sure what exactly you have in mind there. 
> I don't see any open CVEs or bugs tagged with security against gvfs.

I found a security hole in the vfat driver as an idiot kid ~20 years ago,
before I even started using Linux myself.  That particular filesystem is
simplicistic enough to _possibly_ be exploitable bug free by now, but as a
btrfs@vger regular, I hear about enough unintentional corruption caused
failures that I see no way the filesystem could be secured against a
malicious image without an extreme effort that would also destroy
performance.  And that's a maintained filesystem.  We do, in our default
kernel, ship drivers for so many obscure filesystems no one has used for
years that I'm 100% certain you can find an arbitrary code execution bug
triggerable by just mounting such an untrusted USB stick.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄ nearly two years of no catch!)

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

[Vincent Bernat]

 ❦  6 juin 2017 15:55 +0200, Adam Borowski  :

> pulseaudio: xfce4-pulseaudio-plugin
> * BAD: I want working sound, duh.

From now on, you may be more likely to get sound with pulseaudio than
without due to upstreams dropping support for Alsa. See for example
Firefox. And the trend will continue since it's easier to write stuff
for PulseAudio than for Alsa. Maybe it would be better to solve the
problem you have with PulseAudio instead of just ranting (the only bug I
have found you reported against pulseaudio [0] was left unanswered on
your side despite very clear instructions on what to provide to help).

[0]: https://bugs.freedesktop.org/show_bug.cgi?id=84667
-- 
Avoid unnecessary branches.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

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

[Afif Elghraoui]

على الإثنين  5 حزيران 2017 ‫09:52، كتب Scott Kitterman:
>> The answer to that is not clear from the maintainer's response; nor is
>> it clear from what the submitter has written whether they know the
>> answer.
> Why is that question relevant?  The policy definition of Recommends (versus 
> Suggests) has nothing to with if there will be a failure or not:
> 
>> The Recommends field should list packages that would be found together with
>> this one in all but unusual installations

That's not the complete definition of Recommends. The part you left out
states that there should be a strong, but not absolute dependency.
Presumably their being almost always found together on all but unusual
installations is a consequence of that.

> Personally, I think the maintainer articulated what he views as the usual 
> situation and declines to remove Recommends that are, in the maintainer's 
> view, appropriate.  His rationale makes complete sense to me.
>  I'm not saying 
> there aren't other, reasonable choices that could be made, but it make sense. 
>  
> I don't think this is the kind of thing the TC should even entertain 
> overruling a maintainer on.

It's not about targeting the maintainer. It's about clarifying what
should be done. I'd be happy to know whether I should have turned the
pbhoney Recommends into a Depends to avoid unwarranted fallback behavior
when people disable Recommends to avoid numerous unneeded packages.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

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

[Afif Elghraoui]

على الثلاثاء  6 حزيران 2017 ‫04:42، كتب Jonas Smedegaard:
> Quoting Ghislain Vaillant (2017-06-06 10:13:55)
>>
>> Given this is a Python package, we should not even have to argue about 
>> package relationships. Setuptools metadata provides install_requires 
>> and extras_require, the former mapping to Depends, the latter to 
>> Suggests. Period.
>>
>> Your typical Python project README would instruct users to install the 
>> Python package via `pip install`. If one runs `pip install networkx`, 
>> the graphics dependencies do not get pulled. That alone is enough to 
>> justify that these dependencies should not go to Recommends.
>>
>> FYI, I have a similar problem with sympy (#861741), which pulls an 
>> insane amount of packages via chained Recommends.
> 
> We should certainly continue to align package relations with Debian 
> Policy - and therefore by extension continue to argue about that as 
> necessary to evolve Debian Policy:
> 
> Upstream (or other) package relation hints can be a valuable _aid_ in 
> resolving Debian package relations, but only that: An aid!
> 
> Debian packaging follows Debian Policy - other hints do not.
> 

Both good points, but upstream is in the best position to decide whether
something is a strong-yet-not-absolute-dependency (Recommends) of their
software. What Ghislain is saying about Python packages here makes a lot
of sense to me.

regards
Afif
-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

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

[Steve Langasek]

On Tue, Jun 06, 2017 at 11:08:30PM +0200, Michael Biebl wrote:
> Am 06.06.2017 um 18:06 schrieb Russ Allbery:
> > Adam Borowski  writes:

> >> libpam-systemd: xfce4-power-manager xfce4-session
> >> * BAD: Depends:systemd, utterly pointless without it.

> > This is a whole other discussion, but we had *endless* discussions of
> > this, and there are very sound technical reasons for structuring the
> > dependency chain this way.

> xfce4-power-manager, xfc4-session recommending libpam-systemd (or even
> requiring libpam-systemd) seems correct, as those use systemd-logind.

> The Recommends systemd-sysv | systemd-shim is superfluous and should be
> dropped. It's an implementation detail whether systemd (PID 1) or
> systemd-shim provides the functionality needed by
> libpam-systemd/systemd-logind.

If they interface with the dbus APIs directly, they ought to express a
relationship on systemd-sysv | systemd-shim since systemd-shim is not
guaranteed to be already installed on a system booted without systemd.

If they don't interface with the apis and only use them via libpam-systemd,
then libpam-systemd already has this dependency and the separate recommends
could be dropped.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

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

[Paul Wise]

On Tue, Jun 6, 2017 at 9:55 PM, Adam Borowski wrote:

> bash-completion: bash dput-ng licensecheck
> * DEBATABLE: I like the Tab key to do something reasonable,
>   "bash-completion" means you never know what you'll get.

I definitely would not want to run a Debian system that didn't have
bash-completion installed. Being able to tab complete command-line
arguments and apt package names are two examples of invaluable
features this package provides.

> fonts-cantarell: fontforge-common
> * BAD: FontForge works perfectly without it

Cantarell is the default font in the UI, changing it would mean Debian
FontForge would look very different to FontForge on other distros.

https://codesearch.debian.net/search?q=Cantarell+package%3Afontforge

> freepats: libwildmidi-config timidity
> * BAD: freepats is too ugly to live: abysmal quality, lacks instruments for
>   pretty much any .mid file in the wild.  We do have a bunch of good
>   alternatives.  timgm6mb-soundfont for one is 5.6 times smaller yet is
>   complete.

We probably need a pair of virtual packages for this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

[Philipp Kern]

On 06/06/2017 11:52 PM, Adam Borowski wrote:
>> As for "security hole", I'm not sure what exactly you have in mind there. 
>> I don't see any open CVEs or bugs tagged with security against gvfs.
> I found a security hole in the vfat driver as an idiot kid ~20 years ago,
> before I even started using Linux myself.  That particular filesystem is
> simplicistic enough to _possibly_ be exploitable bug free by now, but as a
> btrfs@vger regular, I hear about enough unintentional corruption caused
> failures that I see no way the filesystem could be secured against a
> malicious image without an extreme effort that would also destroy
> performance.  And that's a maintained filesystem.  We do, in our default
> kernel, ship drivers for so many obscure filesystems no one has used for
> years that I'm 100% certain you can find an arbitrary code execution bug
> triggerable by just mounting such an untrusted USB stick.

On the other hand gvfs is not a kernel driver but a userspace filesystem
and hence has a different threat surface. (Sure, there's still the
possibility of arbitrary code execution from content on a network file
system, but that's then shared with other GNOME applications using it.)

Kind regards
Philipp Kern

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

[Jonas Smedegaard]

Quoting Afif Elghraoui (2017-06-07 01:44:45)
> 
> على الثلاثاء  6 حزيران 2017 ‫04:42، كتب Jonas Smedegaard:
>> Quoting Ghislain Vaillant (2017-06-06 10:13:55)
>>>
>>> Given this is a Python package, we should not even have to argue 
>>> about package relationships. Setuptools metadata provides 
>>> install_requires and extras_require, the former mapping to Depends, 
>>> the latter to Suggests. Period.
>>>
>>> Your typical Python project README would instruct users to install 
>>> the Python package via `pip install`. If one runs `pip install 
>>> networkx`, the graphics dependencies do not get pulled. That alone 
>>> is enough to justify that these dependencies should not go to 
>>> Recommends.
>>>
>>> FYI, I have a similar problem with sympy (#861741), which pulls an 
>>> insane amount of packages via chained Recommends.
>>
>> We should certainly continue to align package relations with Debian 
>> Policy - and therefore by extension continue to argue about that as 
>> necessary to evolve Debian Policy:
>>
>> Upstream (or other) package relation hints can be a valuable _aid_ in 
>> resolving Debian package relations, but only that: An aid!
>>
>> Debian packaging follows Debian Policy - other hints do not.
>> 
>
> Both good points, but upstream is in the best position to decide 
> whether something is a strong-yet-not-absolute-dependency (Recommends) 
> of their software. What Ghislain is saying about Python packages here 
> makes a lot of sense to me.

Upstreams of Python projects are "in the best position to decide" about 
_PyPI_ hinting.

What we discuss here is _Debian_ hinting, which is not necessarily the 
same, even if labels are identically/equivalently named.

Debian maintainers are in the best position to decide about Debian 
hinting.  Taking upstream hinting into consideration is quite sensible, 
but *not* authoritative not "best" for _Debian_ hinting.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

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

[Wouter Verhelst]

On Tue, Jun 06, 2017 at 03:55:48PM +0200, Adam Borowski wrote:
> On Mon, Jun 05, 2017 at 05:39:41PM -0700, Russ Allbery wrote:
> > Maybe someone has a list of things they view as Recommends inflation that
> > have (a) been reported as bugs to the appropriate package maintainers, and
> > (b) have been rejected by those package maintainers?  Those are the
> > controversial ones that we'd need to talk about.
> 
> Here's something even better: an automated way to list bad Recommends that
> personally affect you -- ones that made you take steps to ignore them when
> installing a package you actually use:
> 
> ..--==[ list-unsatisfied-recommends ]
> #!/usr/bin/python
> import apt
> c = apt.Cache()
> for pkg in c:
> if pkg.installed is not None:
> for rd in pkg.candidate.get_dependencies("Recommends"):
> if not rd.installed_target_versions:
> print pkg, rd
> `
> 
> Forgot whom to credit for this tool; alas, it's written in a language that
> itself is bloat[1].
> 
> More seriously, though, let's go through the list of 94 unsatisfied ones on
> my desktop; the list below is transposed to collate recommendees.
> 
> 
> Categories:
> OK: "Recommends:" looks warranted
> DEBATABLE: duh.
> BLOAT: potentially useful but I wouldn't make it a Recommends
> BAD: downgrade please
> TRANSITIVELY BAD: useful for a direct user but not when pulled via a
> dependency -or- causes this lower in the chain
> 
> : libreoffice-base
> * BLOAT: they're no longer owned by Sun, what's the reason to keep Java
>   scripting?

Actually, there's significant functionality for some part of
libreoffice-base (this is not the "core" of libreoffice, but the
database component) that's implemented in Java. You can still use
libreoffice-base without java, but that functionality won't be available
then.

I think that's a perfect match for "all but unusual" here.

> dnsmasq-base: lxc
> * BAD: how often are you on a network without a DNS server?

This is about lxc being able to resolve the other containers and the
host system, not about other machines on the network.

You may not be interested in that, but it seems as a perfectly
reasonable thing for a recommends to me.

[...]
> fonts-cantarell: fontforge-common
> * BAD: FontForge works perfectly without it

Yes, but isn't there missing functionality then? If so, that makes
perfect sense.

> fonts-noto-cjk: fonts-noto
> * BLOAT: unlike greek/runes/etc, you can't learn Chinese hieroglyphs on a
>   whim, thus it's useless for most users.  You may want a _single_ CJK font
>   so you can tell whether a text is in C, J or K but that's it.

I think this is something that can only reasonably be decided by someone
who actually speaks the languages in question.

> freedoom | game-data-packager: prboom-plus
> * DEBATABLE: freedoom is too ugly to live, shareware Doom has assets missing
>   for running pretty much anything Doom-related (and AFAIK its license
>   forbids add-ons).  On the other hand, this is an excuse for Doom engines
>   in main.

freedoom is quite fun, actually, IMHO. I think this should be a Depends
rather than a Recommends, but perhaps there's a way to use a doom engine
without wads? Dunno.

[...]
> ghostscript: gimp imagemagick-6.q16 libmagickcore-6.q16-3 netpbm
> * BAD: why would editing images care about a grossly obsolete _document_
>   format?

PostScript is often used to store images, too. All these tools use
ghostscript as an import filter for opening those files.

It makes perfect sense to me?

[...]
> gnupg-l10n: gnupg
> * DEBATABLE: I don't think anyone tech skilled enough to use GPG would have
>   problems with English, but localization is important.  On the other hand,
>   this is 4.5MB in the default install.

No. Just, no. i18n is not a "feature" that we should disable by default.
It should be on by default. Users should not have to check every time
they use a program whether there's i18n files.

There is no stronger example than this to show the "all but unusual"
argument, IMO.

[...]
> libaacs0: libbluray1
> * BLOAT: useful only if you rip optical media

Yes, but essential if you do.

> libclass-xsaccessor-perl: libmoo-perl
> * BLOAT: wut?

They make things go much faster ("The XS accessor methods were between
1.6 and 2.5 times faster than typical pure-perl accessors in some simple
benchmarking.", the description says). However, since it's written in C,
it's not guaranteed to work everywhere. If they're not available or
buggy on your architecture, you might still want to be able to say "use
Moo;" without running into issues, but the normal way of using
libmoo-perl is to have libclass-xsaccessor-perl installed, too.

How is that in any way "bloat"?

> libgit-wrapper-perl: devscripts
> * : I've never used git-deborig, is it actually useful?  Tiny package,
>   though.

devscripts has an "interesting" way to categorize recommends and
depends. Some of them are debateable, but they are internally
consistent.

> libgnomeui-0: xscreensaver
>

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

[Wouter Verhelst]

On Wed, Jun 07, 2017 at 12:29:05PM +0800, Paul Wise wrote:
> On Tue, Jun 6, 2017 at 9:55 PM, Adam Borowski wrote:
> 
> > bash-completion: bash dput-ng licensecheck
> > * DEBATABLE: I like the Tab key to do something reasonable,
> >   "bash-completion" means you never know what you'll get.
> 
> I definitely would not want to run a Debian system that didn't have
> bash-completion installed. Being able to tab complete command-line
> arguments and apt package names are two examples of invaluable
> features this package provides.

Yeah, but I agree with the general feeling that it's extremely annoying
when bash-completion *removes* file names as completion options.
Sometimes the completion has a whitelist of possible filenames; when
that whitelist is incomplete or does not match my system, bash
completion does not help (on the contrary). Yes, it's possible to force
filename completion with alt-shift-/ (at least on my BE AZERTY
keyboard), but that requires a different keystroke than just "tab".

I think if bash had an option to allow programmable completion to add
additional completion options but not remove others, that would be much
much much more interesting.

[...]
-- 
Help me, off-by-one kenobi. You're my only nought.

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

[Ian Jackson]

Paul Wise writes ("Re: Too many Recommends (in particular on 
mail-transport-agent)"):
> On Tue, Jun 6, 2017 at 9:55 PM, Adam Borowski wrote:
> > bash-completion: bash dput-ng licensecheck
> > * DEBATABLE: I like the Tab key to do something reasonable,
> >   "bash-completion" means you never know what you'll get.
> 
> I definitely would not want to run a Debian system that didn't have
> bash-completion installed. Being able to tab complete command-line
> arguments and apt package names are two examples of invaluable
> features this package provides.

I recognise that many feel that way; personally I hate bash-completion
and turn it off.  But that's beside the point.

Whether installing bash-completion is a good idea on a particular
system depends on the opinions and tastes (and finger macros) of its
administrators and users.  It does not depend on whether dput-ng or
licensecheck are installed.  So there the dput-ng and licensecheck
Recommends are silly.

And they cause actual lossage: bash-completion is installed by
default, so if it is not installed that's because the administrator
wanted it that way.  Trying to install dput-ng or licensecheck should
not pull in bash-completion as a side-effect.

The Recommends from bash is just the way that it gets installed by
default.  I think it would be better for it to be in tasksel.  A very
minimal machine (with no tasks, or some very minimal task) will work
fine with bash but without bash-completion.

AFAICT none of these three have been filed as a bug yet so I will do
that right away for dput-ng and licensecheck.

I guess for bash, the right answer would be to file bugs against
tasksel and bash, and block the bash bug with the tasksel bug ?

FAOD I am not trying to change the usual default from `with
bash-completion' to `without bash-completion'.  I'm just trying to
arrange that it's slightly easier not to have bash-completion if you
want to, and that it doesn't come back unexpectedly if you deinstall
it.

Ian.

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

[Christian Seiler]

Hi there,

Am 2017-06-06 15:55, schrieb Adam Borowski:

pulseaudio: xfce4-pulseaudio-plugin
* BAD: I want working sound, duh.


I know there's a faction of people out there who absolutely despise
PulseAudio, and that they constantly have problems with it. But,
as a request collective to all of you that fall into this category:
could you please stop with these snide remarks?

There are other people out here, such as myself, who are really
glad for PulseAudio, and that have never experienced their sound
not to work at all with PA. (Before Jessie I did run into some
issues on some combinations of hardware and software, but all were
solvable, and in the end I was always able to run the configuration
I wanted.)

Now I'm not writing that to try to convince you about PA, and I
don't doubt that you've apparently had trouble with it. And I don't
have a dog in this fight really because I'm not really attached to
PA: if something better comes along in the future, I'd be very
happy to switch. However, what these kind of snide remarks do is
to poison the discussion atmosphere.

To give you an example where I don't like a bit of software: I
really don't like GNOME. But I don't make a habit of going around
and dropping snide remarks such as "I want a usable desktop" [*],
especially in generic discussions. I think this is very counter-
productive.

Or to look at it from this perspective: what I find troubling
here is the apparent lack of recognition that people other than
you might see actual advantages in PA. These kind of remarks come
across as quite condescending to all the people who've looked at
the same software and come to a different conclusion.

Regards,
Christian

PS: Btw. you're objecting to a package with 'pulseaudio' in its
name to recommend the pulseaudio package itself? I think
that this Recommends is a prime example for something that
really makes sense here. In this case the recommends is
fully justified anyway, because the XFCE4 maintainers have
apparently decided that PA should be used by default on
XFCE4 desktops, which is why xfce4 (meta package) Depends:
on xfce4-pulseaudio-plugin.

So in the end, if you don't like PA, then you have two
options here:

  a. Accept the fact that PA is installed by default on
 XFCE4 desktops, be glad that the dependency from the
 XFCE4 plugin to PA itself is only a Recommends: and
 not a Depends:, and remove the package manually. This
 is what Recommends: is for, after all.

   - or -

  b. Convince the XFCE4 people to not make use of PA in the
 default install.

But the Recommends: relationship between the plugin and PA
itself makes perfect sense here.

[*] Which, btw. I would never say about GNOME regardless,
because while I don't like a lot of things they've done, I
wouldn't call it "unusable".

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

[Christian Seiler]

Hi there,

I think one of the main problems with Recommends: is not
actually the dependencies of packages themselves (I think
that most things in your list I disagree with, those
Recommends: are fine in my eyes), but rather in the way
they are handled in APT.

Let me make a couple of points (some are problems, some are
suggestions):

 - You install package A, which Recommends: B, but you don't
   want B, notice that at the time, and either remove B
   afterwards, or install A with --no-install-recommends. But
   then you install package C at a later point in time, which
   actually depends on B. You notice that C is not what you
   wanted, purge it again, but apt-get autoremove will _not_
   remove B, even though it's automatically installed, because
   A recommends it.

   So basically, the following command sequence may or may not
   leave your system in an identical state, depending on the
   packages that previously have been installed on your system:

  apt-get install A
  apt-get purge A
  apt-get autoremove --purge

   Unfortunately, I don't see a good solution to this problem,
   and I've thought about this a lot in the past.

 - When installing APT's text UI doesn't differentiate between
   extra packages that were full dependencies, and those that
   were just recommends. What would be great if APT could
   somehow show this information.

 - My guess is that most power users don't use any GUI, but
   the command line client, for installing packages. (Like I
   do.) However, it would be great if there could be some
   possibility of dropping individual Recommends even with
   the minimalistic text UI of APT.

   Example:

 # apt-get install $pkg
 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 The following additional packages will be installed:
   $pkg2 $pkg3 $pkg4
 Of these, the following only due to a recommendation:
   $pkg3 $pkg4
 Suggested packages:
   $pkg5 $pkg6
 The following NEW packages will be installed:
   $pkg $pkg2 $pkg3 $pkg4
 0 upgraded, 4 newly installed, 0 to remove and 0 not
 upgraded.
 Need to get 42 MB of archives.
 After this operation, 108 MB of additional disk space will
 be used.
 Do you want to continue? [Y/c/n]

   Where the 'c' button will first show a help (in case a more
   inexperienced user presses it accidentally) and then allow
   the user to remove packages from the list if they are pulled
   in via Recommends: - transitively or intransitively.

 - Instead of globally selecting "no recommends", it would be
   great if one could use something like apt-preferences to
   indicate that certain packages should not be installed
   unless they are manually selected _or_ they are actual hard
   Depends:-dependencies of other packages that do not fall
   in this category. Then one could for example make sure that
   -doc packages aren't installed unless they are hard
   Depends:.

 - What could also be nice would be a new dependency type that
   works like this: if the package that declares this
   dependency has been pulled in via Depends: or manually by
   the user, it should act like Recommends:, otherwise like
   Suggests:.

   For example:

  A
Depends: B
Recommends: C
  B:
Depends: D
Recommends: E
Intransitive-Recommends: F
  C:
Depends: G
Recommends: H
Intransitive-Recommends: I
  G:
Intransitive-Recommends: J

   Then "apt-get install A" would yield the following package
   list:

  A (duh)
  B (Depends)
  C (Recommends)
  D (Depends -> Depends)
  E (Depends -> Recommends)
  F (Depends -> Intransitive-Recommends)
  G (Recommends -> Depends)
  H (Recommends -> Recommends)

   Not pulled in:

  I (Recommends -> Intransitive-Recommends)
  J (Recommends -> Depends -> Intransitive-Recommends)

   (Feel free to bikeshed over the name.)

   This could make the transitivity issue of Recommends:
   easier to deal with. Unfortunately this has some weird
   side-effects: if you mark a specific package as manually
   installed later, their Intransitive-Recommends: would need
   to change from effective Suggests: to effective Recommends:,
   which means APT somehow needs to figure out that it should
   install them. Disadvantage: APT would need to add support
   for this at the beginning of the Buster cycle, but it
   could only be used in the archive starting with Buster+1,
   otherwise upgrades from Stretch wouldn't work.

I'm not sure how good of an idea each of these is, but maybe
they could provide some inspiration for this topic.

Regards,
Christian

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

[Johannes Schauer]

Quoting Christian Seiler (2017-06-07 15:26:35)
>   - You install package A, which Recommends: B, but you don't
> want B, notice that at the time, and either remove B
> afterwards, or install A with --no-install-recommends. But
> then you install package C at a later point in time, which
> actually depends on B. You notice that C is not what you
> wanted, purge it again, but apt-get autoremove will _not_
> remove B, even though it's automatically installed, because
> A recommends it.
> 
> So basically, the following command sequence may or may not
> leave your system in an identical state, depending on the
> packages that previously have been installed on your system:
> 
>apt-get install A
>apt-get purge A
>apt-get autoremove --purge
> 
> Unfortunately, I don't see a good solution to this problem,
> and I've thought about this a lot in the past.

You may want to have a look at the following apt configuration setting:

APT::AutoRemove::RecommendsImportant "false";

It controls whether "autoremove" also considers autoremoving packages that are
only pulled in because of a Recommends relationship.

Thanks!

cheers, josch


signature.asc
Description: signature

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

[Christian Seiler]

Am 2017-06-08 16:07, schrieb Johannes Schauer:

Quoting Christian Seiler (2017-06-07 15:26:35)

  - You install package A, which Recommends: B, but you don't
want B, notice that at the time, and either remove B
afterwards, or install A with --no-install-recommends. But
then you install package C at a later point in time, which
actually depends on B. You notice that C is not what you
wanted, purge it again, but apt-get autoremove will _not_
remove B, even though it's automatically installed, because
A recommends it.

So basically, the following command sequence may or may not
leave your system in an identical state, depending on the
packages that previously have been installed on your system:

   apt-get install A
   apt-get purge A
   apt-get autoremove --purge

Unfortunately, I don't see a good solution to this problem,
and I've thought about this a lot in the past.


You may want to have a look at the following apt configuration setting:

APT::AutoRemove::RecommendsImportant "false";

It controls whether "autoremove" also considers autoremoving packages 
that are

only pulled in because of a Recommends relationship.


Well, that doesn't really help in this case.

In my scenario, I do have Recommends installed by default, I just
may decide to not install some Recommends in some cases. In that
case, apt-get autoremove with the setting you suggested would
remove a _ton_ of packages I actually want to keep. Your setting
is only useful if you also disable installing Recommends by default.
In that case, yes, it would help.

Regards,
Christian

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

[Adrian Bunk]

On Wed, Jun 07, 2017 at 03:26:35PM +0200, Christian Seiler wrote:
>...
>  - You install package A, which Recommends: B, but you don't
>want B, notice that at the time, and either remove B
>afterwards, or install A with --no-install-recommends. But
>then you install package C at a later point in time, which
>actually depends on B. You notice that C is not what you
>wanted, purge it again, but apt-get autoremove will _not_
>remove B, even though it's automatically installed, because
>A recommends it.
> 
>So basically, the following command sequence may or may not
>leave your system in an identical state, depending on the
>packages that previously have been installed on your system:
> 
>   apt-get install A
>   apt-get purge A
>   apt-get autoremove --purge
> 
>Unfortunately, I don't see a good solution to this problem,
>and I've thought about this a lot in the past.
>...

apt-get blacklist-from-recommends-install B
(or a similar entry in a configuration file)

This would help people who have a strong need/desire to opt out of some 
specific package (e.g. pulseaudio) when it would otherwise be pulled in 
through recommends.

> Regards,
> Christian

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

[Nikolaus Rath]

On Jun 08 2017, Adrian Bunk  wrote:
> On Wed, Jun 07, 2017 at 03:26:35PM +0200, Christian Seiler wrote:
>>...
>>  - You install package A, which Recommends: B, but you don't
>>want B, notice that at the time, and either remove B
>>afterwards, or install A with --no-install-recommends. But
>>then you install package C at a later point in time, which
>>actually depends on B. You notice that C is not what you
>>wanted, purge it again, but apt-get autoremove will _not_
>>remove B, even though it's automatically installed, because
>>A recommends it.
>> 
>>So basically, the following command sequence may or may not
>>leave your system in an identical state, depending on the
>>packages that previously have been installed on your system:
>> 
>>   apt-get install A
>>   apt-get purge A
>>   apt-get autoremove --purge
>> 
>>Unfortunately, I don't see a good solution to this problem,
>>and I've thought about this a lot in the past.
>>...
>
> apt-get blacklist-from-recommends-install B
> (or a similar entry in a configuration file)

I might be able to get this today when using debfoster ("negative
keepers").

Best,
Nikolaus


-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

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

[Anthony DeRobertis]

Using you script, it doesn't seem to be too bad. I went through a few 
machines:



I went through the ones on my desktop here (running testing). Excluding 
non-Debian packages, I found:


blktrace Recommends: libtheora-bin, libav-tools, librsvg2-bin

   I suspect these are required for iowatcher (one of the three tools
   in the package) to run. I personally just use blktrace and blkparse;
   I think it's reasonable if the maintainer considers iowatcher
   important as well. But it is a huge dependency chain, especially for
   libav-tools (which nowadays is a transitional package for ffmpeg).


firmware-linux Recommends: amd64-microcode
firmware-linux-nonfree Recommends: amd64-microcode

   This machine has an Intel CPU. It should probably recommend
   intel-microcode | amd64-microcode instead of both. Though we are
   talking about an Installed-Size of 68 here.


geoclue-2.0 Recommends iio-sensor-proxy, modemmanager, wpasupplicant

   My desktop has none of this hardware. Network is wired Ethernet. It
   does have temperature sensors, though I doubt the CPU temperature is
   too useful for finding my location. (Given, geoclue is probably
   pretty useless on my box.)


get-flash-videos Recommends: get-iplayer

   I don't live in the UK, and AFAIK iplayer is geo-restricted to the UK.

vlc Recommends: vlc-plugin-samba (and a few others)

   Note this plugin is only needed to access Samba shares that aren't
   mounted (it's samba client in userspace). Seems like it's perfectly
   reasonable to only play mounted videos, or ones from network
   streams. VLC has a few more plugins in Recommends that I have installed.


There are various packages that Recommends: their -doc packages; those 
probably sense if you've installed them directly, but are annoying when 
the package has come in as a dependency.


There are of course a bunch more unsatisfied recommends, but they don't 
strike me as weird (e.g., where I've elected not to install -i18n packages).




On a home server, running Jessie—the script failed ("AttributeError: 
'Dependency' object has no attribute 'installed_target_versions'"). I 
don't know enough (any) Python to fix it.



On another desktop (at work) running testing (and ignoring ones already 
mentioned above):


hplip Recommends: sane-utils

   Printer is just a printer. Doesn't have a scanner.

libsane Recommends: sane-utils >= 1.0.25-4.1

   Don't have a scanner. (libsane is pulled some Depends). AFAIK -util
   is some programs to use SANE, not things called by the library.

openvpn Recommends: easy-rsa

   Unsure about this one. I have it a bunch of places, but the average
   person probably doesn't want to use the OpenSSL command line. Though
   certificate management is a once every X years problem, except on
   your CA.

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

[Ben Hutchings]

On Fri, 2017-06-09 at 03:02 -0400, Anthony DeRobertis wrote:
[...]
> firmware-linux Recommends: amd64-microcode
> firmware-linux-nonfree Recommends: amd64-microcode
> 
> This machine has an Intel CPU. It should probably recommend
> intel-microcode | amd64-microcode instead of both. Though we are
> talking about an Installed-Size of 68 here.
[...]

Then APT would never automatically install amd64-microcode.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program than to understand a correct
one.



signature.asc
Description: This is a digitally signed message part

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

[Ivan Shmakov]

> Adam Borowski  writes:
> On Mon, Jun 05, 2017 at 05:39:41PM -0700, Russ Allbery wrote:

 >> Maybe someone has a list of things they view as Recommends inflation
 >> that have (a) been reported as bugs to the appropriate package
 >> maintainers, and (b) have been rejected by those package
 >> maintainers?  Those are the controversial ones that we'd need to
 >> talk about.

[…]

 > bash-completion: bash dput-ng licensecheck

 > * DEBATABLE: I like the Tab key to do something reasonable,
 > "bash-completion" means you never know what you'll get.

FWIW, I agree wholeheartedly with this one.  (The only reason I
don’t have ‘complete -r’ in my ~/.bashrc is that bash-completion
is rarely if ever installed on the systems I frequently use.)

[…]

 > freedoom | game-data-packager: prboom-plus

 > * DEBATABLE: freedoom is too ugly to live, shareware Doom has assets
 > missing for running pretty much anything Doom-related (and AFAIK its
 > license forbids add-ons).  On the other hand, this is an excuse for
 > Doom engines in main.

The latter seems like a good enough reason for this dependency.

 > freepats: libwildmidi-config timidity

 > * BAD: freepats is too ugly to live: abysmal quality, lacks
 > instruments for pretty much any .mid file in the wild.  We do have a
 > bunch of good alternatives.  timgm6mb-soundfont for one is 5.6 times
 > smaller yet is complete.

Probably a relic of the days long gone; I guess it should be
updated to include some more alternatives (in preference to
freepats) – so long as timidity can (be made to) actually use
any of them “out-of-box.”

Package: freepats
Version: 20060219-1
…
Description-en: Free patch set for MIDI audio synthesis
…
 It is, however, the sole DFSG-compliant patch set in existence so far.
 New patches (including those in better formats, such as SF2 SoundFont banks)
 are welcome.

[…]

 > gfortran-mingw-w64: gcc-mingw-w64

 > * BAD: seriously, Fortran?

Fortran is still widely used (in niche applications; WRF comes
to mind), but I see no good reason for this dependency.

 > ghostscript: gimp imagemagick-6.q16 libmagickcore-6.q16-3 netpbm

 > * BAD: why would editing images care about a grossly obsolete
 > _document_ format?

So that one can $ convert  pic.ps pic.png?  Or (I suspect)
$ convert  file.pdf file.png, for that matter.

(Or perhaps more sensibly: $ display  pic.ps pic.pdf.)

Moreover, PostScript is a programming (code) language – not a
(data) format.

I’m neutral on this dependency, though.  I do like PostScript
for a document format as much as I do like JavaScript for the
same, but I see how it may be nice to support .ps (and .pdf?)
rasterization in ImageMagick and Gimp “out-of-box.”

[…]

 > gnat-mingw-w64: gcc-mingw-w64

 > * BAD: see Fortran.

Agreed.

 > gnupg-l10n: gnupg

 > * DEBATABLE: I don't think anyone tech skilled enough to use GPG
 > would have problems with English, but localization is important.
 > On the other hand, this is 4.5MB in the default install.

Well, ‘locales’ is about 9 MiB in the same, so…

[…]

 > libhtml-format-perl: libhtml-tree-perl libwww-perl

 > * : wut?

… Me neither.

 > libhttp-daemon-perl: libwww-perl

 > * TRANSITIVELY BAD: dependency comes from a client package; if I want
 > to run a http server I know where to find it

That’s only Installed-Size: 71, so I don’t see much of a
problem.  AIUI, libwww-perl (as per upstream) had the
HTTP::Daemon library for decades, thus not installing one by
default in Debian may easily surprise an unsuspecting user.

[…]

 > libpackage-stash-xs-perl: libpackage-stash-perl

 > * TRANSITIVELY BAD: dependencies pulling more dependencies, why?

I suppose that’s so one’s Perl script can be Architecture: all,
instead of depending on either pure-Perl or an XS (binary)
implementation of the package – depending on the architecture.

[…]

 > libpurple-bin: libpurple0

 > * BAD: a library has no reason to install programs

My exact reaction on seeing that Mutt transitively Depends: on
GnuPG – all thanks to libgpgme11 depending on the latter.

I do not know about this specific case, but I very much agree
with the principle.

[…]

 > libtasn1-doc: libtasn1-6-dev

 > * TRANSITIVELY BAD: probably useful if you do TASN (whatever it is),
 > pulled in by a very-widespread library (gnutls)

That’s Abstract Syntax Notation One (or ASN.1), and while I use
it all the time (notation, that is; not this specific library at
the moment), I see no reason for a -dev package to depend on a
-doc one any stronger than with a mere Suggests:.

[…]

 > transfig: inkscape

 > * BLOAT: a badly obsolete image format, pulls in ghostscript and
 > other crap

Curiously enough, I still find XFig – with all its nume

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

[Stephen Kitt]

On Sun, 11 Jun 2017 06:12:23 +, Ivan Shmakov  wrote:
> > Adam Borowski  writes:
>  > gfortran-mingw-w64: gcc-mingw-w64  
> 
>  > * BAD: seriously, Fortran?  
> 
>   Fortran is still widely used (in niche applications; WRF comes
>   to mind), but I see no good reason for this dependency.

Backwards-compatibility, gcc-mingw-w64 used to include the Fortran compiler.
I meant to leave the Recommends there for one cycle and remove it, but forgot
— it will be gone in Buster.

>  > gnat-mingw-w64: gcc-mingw-w64  
> 
>  > * BAD: see Fortran.  
> 
>   Agreed.

See above.

Regards,

Stephen


pgptw6LGk16se.pgp
Description: OpenPGP digital signature

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

[Russ Allbery]

Ivan Shmakov  writes:

>   That’s Abstract Syntax Notation One (or ASN.1), and while I use
>   it all the time (notation, that is; not this specific library at
>   the moment), I see no reason for a -dev package to depend on a
>   -doc one any stronger than with a mere Suggests:.

We have some specific Policy about this:

https://www.debian.org/doc/debian-policy/ch-docs.html#s-docs-additional

If package is a build tool, development tool, command-line tool, or
library development package, package (or package-dev in the case of a
library development package) already provides documentation in man,
info, or plain text format, and package-doc provides HTML or other
formats, package should declare at most a Suggests on
package-doc. Otherwise, package should declare at most a Recommends on
package-doc.

If you feel that this should cap the dependency at Suggests across the
board, feel free to submit a bug against debian-policy.  It seems at least
worth a discussion.  Note that this does tend to make upstreams pretty
unhappy, though, since they get questions from confused Debian users who
don't know how to find the documentation that they're "supposed" to have.

-- 
Russ Allbery (r...@debian.org)   

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

[Jeremy Bicha]

On Sun, Jun 11, 2017 at 2:16 PM, Russ Allbery  wrote:
> We have some specific Policy about this:
>
> https://www.debian.org/doc/debian-policy/ch-docs.html#s-docs-additional
>
> If package is a build tool, development tool, command-line tool, or
> library development package, package (or package-dev in the case of a
> library development package) already provides documentation in man,
> info, or plain text format, and package-doc provides HTML or other
> formats, package should declare at most a Suggests on
> package-doc. Otherwise, package should declare at most a Recommends on
> package-doc.

By the way, that paragraph is new in Policy 4.0.0.

Thanks,
Jeremy Bicha

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

[Adam Borowski]

On Sun, Jun 11, 2017 at 11:16:23AM -0700, Russ Allbery wrote:
> Ivan Shmakov  writes:
> > That’s Abstract Syntax Notation One (or ASN.1), and while I use
> > it all the time (notation, that is; not this specific library at
> > the moment), I see no reason for a -dev package to depend on a
> > -doc one any stronger than with a mere Suggests:.
> 
> We have some specific Policy about this:
> 
> https://www.debian.org/doc/debian-policy/ch-docs.html#s-docs-additional
> 
> If package is a build tool, development tool, command-line tool, or
> library development package.  [...] package should declare at most a
> Recommends on package-doc.
> 
> If you feel that this should cap the dependency at Suggests across the
> board, feel free to submit a bug against debian-policy.  It seems at least
> worth a discussion.  Note that this does tend to make upstreams pretty
> unhappy, though, since they get questions from confused Debian users who
> don't know how to find the documentation that they're "supposed" to have.

No, when taken alone, -dev packages Recommending -doc is just right.  There
are very limited cases when you're writing code for a library's API but
don't have an use for its primary documentation.  A person who downloads
the source to mess with the code you've written is also well served by
having the docs available.  On the other hand, the buildds have no use for
documentation (no human in the chroot), and here our policies again work
fine.

The problem is only, once again, with transitive dependencies.  I don't use
libtasn1-dev directly, it's merely required by one of libraries I'm using.

This one isn't a good example (399KB is negligible), but we have some
dependency chains from hell elsewhere.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄ nearly two years of no catch!)

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

[Jeremy Bicha]

On Sun, Jun 11, 2017 at 3:30 PM, Adam Borowski  wrote:
> No, when taken alone, -dev packages Recommending -doc is just right.

https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=dc3b001

Thanks,
Jeremy Bicha

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

[Adam Borowski]

On Sun, Jun 11, 2017 at 03:43:45PM -0400, Jeremy Bicha wrote:
> On Sun, Jun 11, 2017 at 3:30 PM, Adam Borowski  wrote:
> > No, when taken alone, -dev packages Recommending -doc is just right.
> 
> https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=dc3b001

This change talks about only "extra" documentation that's redundant with
what's already shipped in -dev -- ie, cases where you have man pages and
plain text in -dev then HTML and PDF in -doc.

The case of _primary_ documentation being in -doc is still supposed to be
Recommends, which I agree with (save for the transitional dependency issue).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄ nearly two years of no catch!)

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

[Russ Allbery]

Adam Borowski  writes:
> On Sun, Jun 11, 2017 at 03:43:45PM -0400, Jeremy Bicha wrote:
>> On Sun, Jun 11, 2017 at 3:30 PM, Adam Borowski  wrote:

>>> No, when taken alone, -dev packages Recommending -doc is just right.

>> https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=dc3b001

> This change talks about only "extra" documentation that's redundant with
> what's already shipped in -dev -- ie, cases where you have man pages and
> plain text in -dev then HTML and PDF in -doc.

> The case of _primary_ documentation being in -doc is still supposed to
> be Recommends, which I agree with (save for the transitional dependency
> issue).

The change was trying to canonicalize two best practices in Policy: extra
documentation being at most Suggests, as you say, but also that even
primary documentation should not be a *Depends*, but at most a Recommends.
I think that's uncontroversial, and it sounds like people are still
comfortable with primary documentation being a Recommends (well, with the
exception of texlive, which came up in this thread -- that's a hard case
since it's documentation that would fit the definition of Recommends
normally, but it's quite large, and texlive gets pulled in a lot by build
dependencies).

-- 
Russ Allbery (r...@debian.org)   

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

[Anthony DeRobertis]

On Fri, Jun 09, 2017 at 03:21:25PM +0100, Ben Hutchings wrote:
> On Fri, 2017-06-09 at 03:02 -0400, Anthony DeRobertis wrote:
> [...]
> > firmware-linux Recommends: amd64-microcode
> > firmware-linux-nonfree Recommends: amd64-microcode
> > 
> > This machine has an Intel CPU. It should probably recommend
> > intel-microcode | amd64-microcode instead of both. Though we are
> > talking about an Installed-Size of 68 here.
> [...]
> 
> Then APT would never automatically install amd64-microcode.

True. Apt doesn't really have a good solution to that. The only thing
I've seen is 

Recommends: cpu-microcode-all | cpu-microcode

and having a cpu-microcode-all package that Depends on both, and having
the two real package Provides cpu-microcode. If I remember correctly,
Xorg did this at one point for video drivers (maybe still does).

Of course—for the under 100K being saved here, only Rube Goldberg would
approve.

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

[Henrique de Moraes Holschuh]

On Mon, 12 Jun 2017, Anthony DeRobertis wrote:
> Of course—for the under 100K being saved here, only Rube Goldberg would
> approve.

It is a bit less than 1MiB saved on an AMD system when you purge
intel-microcode, but even that is likely to not be considered worth the
cost of the extra (empty) cpu-microcode-all package.

Besides, it is not like these packages waste valuable resources when
installed on a system they don't support, either: by default, once
installed, they detect the processor vendor and go inactive when it
doesn't match the one they are for.

That said, if anyone provides a compelling reason to switch to the
cpu-microcode-all + virtual cpu-microcode scheme (as in: give examples
of how the behavior changes on widely used package managers), and gets
the buy-in from the firmware-nonfree package, I will deploy it for
amd64-microcode and intel-microcode.

-- 
  Henrique Holschuh

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

[Terry McKenna]

Regarding "bloat"

> I think we should take a test case or two to the Technical Committee.

This one may be at the extreme, but it is one I personally encountered. 
I was installing nmap on a system (no gui) and was a bit shocked.  The 
problem is well articulated by one post (an my thanks to him for the 
work around).


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714320#17

> From: BarthezZ 
> I ran into the same issue at a freshly installed Debian 7.0 machine,
> it seems the problem is caused by the dependency on liblinear1 which
> is a new dependency compared to the version in squeeze.
>
> So I looked around in the dependency tree a little, and the eventual
> cause is that liblinear1 recommends liblinear-tools, which in turn
> recommends libsvm-tools, which depends on gnuplot, which happily
> install an x11 version of itself, hence all the X libraries.
>
> Doing the installation with apt-get install nmap --no-install-recommends
> gives us back a "normal" set of dependencies.
>
> With kind regards,
>
> Bart de Heij

I leave the policy debate to the insiders, but I will second the opinion 
that creating a user habit of "ignoring" something is generally a bad idea.


-Terry McKenna

cheers to those that make debian happen.

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

[Jeremy Bicha]

On Mon, Jun 5, 2017 at 8:02 PM, Terry McKenna
 wrote:
> This one may be at the extreme, but it is one I personally encountered. I
> was installing nmap on a system (no gui) and was a bit shocked.  The problem
> is well articulated by one post (an my thanks to him for the work around).
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714320#17

That particular example appears to have been fixed years ago with
https://bugs.debian.org/682062

Thanks,
Jeremy Bicha

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

[Brian May]

On 2017-06-06 10:37, Jeremy Bicha wrote:

> On Mon, Jun 5, 2017 at 8:02 PM, Terry McKenna
>  wrote: 
> 
>> This one may be at the extreme, but it is one I personally encountered. I
>> was installing nmap on a system (no gui) and was a bit shocked.  The problem
>> is well articulated by one post (an my thanks to him for the work around).
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714320#17
> 
> That particular example appears to have been fixed years ago with
> https://bugs.debian.org/682062

714320 [1] was opened in 2013, and people were complaining about 714320
[1] this year. 

682062 [2] was opened and closed in 2012. 

Are people sure that 714320 [1] really is fixed? 

Also it appears 714320 [1] is marked "unreproducible" and is against the
wrong package. 

If 714320 [1] has been fixed, it should be closed, not marked
unreproducible. 

Links:
--
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714320#17
[2] https://bugs.debian.org/682062

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

[Terry McKenna]

I did not intend to drag the conversation off topic.  It was merely an 
attempt to demonstrate the daisy chain effect of bloat.  How a new 
dependency in a CLI tool could daisy chain an install of X11.


(and I thought it was still open).

To clarify and close this tangent...

nmap (bug 714320 open) "dep" on liblinear1 (bug 682062 closed)

Looking solely at the package pages themselves,

stretch/nmap (7.40-1)  ---> dep: liblinear3 (>= 2.01+dfsg) ---> sug: 
liblinear-tools (= 2.1.0+dfsg-2)
jessie/nmap (6.47-3+deb8u2) ---> dep: jessie/liblinear1 (>= 1.6) ---> 
sug: wheezy/liblinear-tools (= 1.8+dfsg-4)
wheezy/nmap (6.00-0.3+deb7u1) ---> dep: wheezy/liblinear1 (>= 1.6)  --- 
rec: wheezy/liblinear-tools (= 1.8+dfsg-1)


The bug only seems to persist in wheezy.  On a freshly built machine 
using debian-stretch-DI-rc4-amd64-i386-netinst.iso, the problem no 
longer persists for me.


-Terry McKenna