Hi,
Russ Allbery <r...@debian.org> writes:
> Gerrit Pape <p...@dbnbgs.smarden.org> writes:
>> and helps us to keep control over the size of required and important.
>
> This is a different issue. You want oversight over what goes into
> required and important. I can certainly see why you want this.
I don't think it helps too much to control size of required and
important packages: it prevents (or in partice does not) adding new
dependencies, but does not stop the packages itself from growing. I
don't care where growth comes from: adding new (small) dependencies or
increasing the size of the package directly has the same effect.
Requiring dependencies to have the same or higher priority does however
create additional busywork: library packages have to be promoted and
demoted. As a random example these packages are currently 'important' in
unstable:
Package: libboost-iostreams1.49.0
Package: libboost-iostreams1.54.0
Package: libboost-iostreams1.55.0
Probably not all of them need to be important any longer, but looking at
that is just busywork and nothing productive...
Having the Priorties be adjusted correctly in both testing and unstable
is also harder if different sets of libraries are involved.
As another example take the 'init' package: on amd64 it Depends:
systemd-sysv | sysvinit-core | upstart. systemd-sysv is important[1],
the alternatives must not be important (they are not coinstallable).
On kfreebsd-*, sysvinit-core must be the Priority: important package,
but priorities are not architecture-specific[2], but as far as I know
having sysvinit-core at a low priority works just fine...
[1] Technically a policy violation too. Maybe we should make it
required, but then people will probably complain too...
[2] And there are various issues in trying to make them so: I don't
think substvars can be used as the Priority of binary packages
ends up in the .dsc.
Finally I'm not sure if it is ftpmaster's task to tell maintainers of
high priority packages what other packages they may depend on. We should
by default just trust them.
Ansgar
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85zjes5plr....@tsukuyomi.43-1.org
