[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#758234: transitive dependencies

On 15/11/14 09:35, Santiago Vila wrote:
> If those are the real reasons, then let's drop the rule only for
> *libraries*, but not for every other package.

I think libraries are merely the most visible and obvious example of
something that is pulled in as an implementation detail of part of the
desired functionality, but is not actually part of the desired set of
functionality itself.

Here are some concrete examples:

An implementation of syslog clearly qualifies for Priority: important
via the "What on earth is going on?" rule: we want systems to have
syslog unless someone has made an effort not to[1]. Our default syslog
implementation is rsyslog. However, rsyslog depends on
init-system-helpers and lsb-base, neither of which is inherently important.

Similarly, isc-dhcp-client is Priority: important because it's our
default DHCP client, and the base system clearly ought to have *some*
DHCP client; but if you want to exclude isc-dhcp-client and install
dhcpcd5 or pump instead, at the moment, you would still get
isc-dhcp-common. Similar reasoning for aptitude and aptitude-common,
tasksel and tasksel-data, vim and vim-common, and so on.

dmidecode is Priority: important despite, AFAICS, neither doing anything
on its own nor being a commonly-invoked sysadmin tool. I assume that's
because laptop-detect used to be Priority: important?

If systemd (Priority: important as our default init system) had resolved
#759293 by adding a Depends on dbus, and dbus had been bumped up to
important as a result, then debootstrap'd systems that selected
sysvinit-core instead of systemd would still get dbus, unnecessarily.

> In fact, I'm not sure that making libc6 optional is a good idea.

Treating the standard C library as a special case seems reasonable; it
is, after all, a special case among libraries already (for instance, it
defines the architecture's ABI).

However, I'm not sure that it would actually be harmful to drop its
priority, since numerous Essential packages depend on it. In particular,
libc-bin is Essential: yes, Priority: required, and depends on libc6 or
the architecture's equivalent. libc-bin certainly qualifies as both
Essential and required, since it contains things like the runtime
dynamic linker, without which the majority of packages won't work.

> BTW: A lot of years ago I tried to make the override file to follow
> the rules without success. What about automating this procedure first?

For the reasons Matthias and I have outlined, I think the current rules
are both unnecessary and harmful. Automating an unnecessary and harmful
thing does not make it any more necessary, or less harmful.


[1] I have worked on a (non-public) Debian 7 derivative which relies on
reconfiguring systemd-journald to enable persistent storage, and does
not have syslog at all, in order to have one fewer way the disk could
fill up. That's one example of a system where an effort has been made
not to have it.

Reply to: