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

Bug#235525: debian-policy: [PROPOSAL] Relax priority relations between packages (Policy 2.5)



Package: debian-policy
Version: 3.6.1
Severity: wishlist

After the discussion started in
http://lists.debian.org/debian-policy/2003/debian-policy-200312/msg00020.html,
I'd now like to formally suggest changing policy.

The following paragraph in section id="priorities" should be changed.

Current text:
        <p>
          Packages must not depend on packages with lower priority
          values (excluding build-time dependencies).  In order to
          ensure this, the priorities of one or more packages may need
          to be adjusted.
        </p>

Proposed text:
	<p> 
	  Packages with priorities required, important, standard and
	  optional must not depend on packages with priority extra
	  (excluding build-time dependencies). In order to ensure
	  this, the priorities of one or more packages may need to be
	  adjusted.
	</p>

Rationale:
The original wording is a legacy from the times when we didn't have
packaging tools as sophisticated as apt, and it was aimed to have
self-contained distributions even if low priorities like extra or
optional have been left off from the distribution medium.

This is not necessary any more since our current archive mirror and CD
creation tools honor dependencies and can automatically pull in lower
priority packages that are depended on by higher priority packages.
The same holds for actual package installation.

Our tools install important packages automatically when they become
available. This includes a fresh installation of Debian where all
important packages are newly available. With the current policy,
packages A and B depended on by C need to be priority important if C
is priority important. If C is - on the local admin's authority -
replaced by D, A and B stay installed because they were originally
installed by virtue of being important. If they were optional, our
packaging tools could remove them because it would know that they were
only installed as dependenies of C. Currently, having this behavior
forces A and B to conflict with each and every package that could be
used to replace C. See the Conflicts: line on exim4-config for a
demonstration of this approach's uglyness.

Additionally, if D is already installed, our tools will automatically
pull in the new important packages A and B which are not needed since
C is not even installed here. Nevertheless, the packages are
downloaded, installed, ask their debconf questions and take up disk
space. This could be avoided by allowing them to be of lower priority.

The rule "people should be able to forget about extra without any
unmet dependenies" is preserved by this proposal. If we were to ditch
this requirement, the replacement text proposed above could be empty.

The current scheme of upping package priorities to Standard and higher
just because they are needed by packages above that line causes
unnecessary cruft on end-user systems.

This proposal may, however, have influence on the CD building process,
but since our tools have been using apt for package selection and
therefore honor package dependencies automagically since 1999, I
seriously doubt that there are still CD builders out there that
blindly choose packages for their priority setting.

OTOH, debian-installer is concerned as well. cdebootstrap needs to
build an in-memory representation of Packages and Dependencies, which
needs polynomial memory per package. debian-installer is therefore
concerned about keeping the number of packages to put into that
representation small. This is especially important on low-memory
installs where less than 32 MB RAM is available.

With this policy chance, debian-installer has to build the in-memory
representation for required, important, standard and optional, and
will need to swap in the process.


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux torres 2.4.21-ipsec #1 Sat Jul 5 11:02:08 UTC 2003 i586
Locale: LANG=C, LC_CTYPE=de_DE




Reply to: