Bug#235525: debian-policy: [PROPOSAL] Relax priority relations between packages (Policy 2.5)
On Thu, Mar 11, 2004 at 02:55:26PM -0600, Manoj Srivastava wrote:
> On Thu, 11 Mar 2004 14:59:09 +0100, Andreas Barth <aba@not.so.argh.org> said:
>
> > * Bill Allombert (allomber@math.u-bordeaux.fr) [040311 00:40]:
> >> As an example I recall the definition of 'standard' in policy 2.5.
> >>
> >> `standard' These packages provide a reasonably small but not too
> >> limited character-mode system. This is what will be installed by
> >> default if the user doesn't select anything else. It doesn't
> >> include many large applications.
> >>
...
> How? What if the dependencies of a standard package now
> includes TeX? Or requires Emacs? Then trying to install standard
> would bring in these huge subsystems, and make the definition of
> `standard' incorrect.
>
> >> > 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.
>
> I do not think that is the correct. We also have some promises
> about sizes of installs, and each level was internally sufficient. I
> think that is a useful technical invarian't, and should not be given
> up lightly.
>
...
>
> But not if we also need to loosen the assertions that were
> possible to make before.
>
> If it is not clear, I think this is a bad idea.
>
> manoj
>
Forgive a mere user for butting in here, but both sides here are
arguing solely on the needs of us users, so let me try to
explain the situation as it looks from a user perspective.
The current policy provides 3 guarantees to the user regarding
the priority labelling of packages, here written as boolean
assertions in an ad hoc notation:
[1] { p | p.priority >= X } is self contained
[2] { p | p.priority >= X } provides functionality level X
[3] |{ p | p.priority >= X }| is reasonably small for level X
With a little logical operations these can be rewritten as
[1 ] closure( { p | p.priority >= X }, (p' depon p) ) ==
{ p | p.priority >= X }
[2'] closure( { p | p.priority >= X }, (p' depon p) )
provides functionality level X
[3'] |closure( { p | p.priority >= X }, (p' depon p) )|
is reasonably small for level X
and further to
[1 ] p' depon p => p.priority >= p'.priority
[2'] levelX depon p => p.priority >= X
[3'] |closure( { p | p.priority >= X }, (p' depon p) )|
is reasonably small for level X
>From these assertions users and tools alike can draw the
following conclusions:
[4 ] p.priority == X & !(E p',p'.priority >= X && p' depon p) =>
levelX depon p
[5 ] p.priority == X & (E p',p'.priority >= X && p' depon p) =>
indeterminate(levelX depon p)
[5 ] is the problem, if the user finds a different way of
satisfying the dependencies of p' or chooses an alternative to
p' over p', then the packaging system provides neither the user,
nor any tool the user might run with any way of knowing if p is
still needed for its own reasons independently of its
relationship with p' .
In order to provide the user or tools with the information
needed to determine if p should be installed or not, there are 6
possibilities:
A. Introduce a new package field
Priority-is-fake-real-priority-is: extra
B. Forego programmatic access and put the info in the package
description of package p
"gnomovision is only marked Important because it is depended
on by bisonbreeder, if you do not install any package that
depend on gnomovision, you can safely remove it even though
dpkg, dselect, apt and aptitude will all warn you that
gnomovision is technically marked as an Important package"
C. Hard code the names of packages in this predicament somewhere
in the sources for dpkg, apt, dselect, aptitude, deity,
debfoster, dinstall etc. etc. Rumors say that debfoster may
be trying to do this.
D. Abuse "Conflicts", "Replaces" etc. by having maintainers
declare such negative relationships between p and all the
alternative ways the user might satisfy the needs of p' or the
need to have p' in the first place.
Some exim-specific packages have successfully resorted to this
hack in order to satisfy policy while still catering to the
needs of the users. This is done as a policy requirement, not
a policy violation.
But if p is a general library or utility which is depended on
by multiple otherwise unrelated packages of various
priorities, this already fragile hack is not workable.
E. Propose a policy change to drop rule [1] and emphasize that
[2'] and [3'] are still MUST requirements enforced by the ftp
master through the override files.
F. Does anyone have a better alternative?
Jakob
P.S.
I understand from another post that the debinstaller team has a
technical problem computing the closure of levelX during the
initial bootstrapping of the system, especially on low memory
systems (I have such systems myself, and need Debian's ability to
install on them). The memory need can be reduced by reading the
Packages file multiple times until all Depends are satisfied.
That way, only the names and versions of packages to be
installed needs to be in memory, not the full package tree.
There is no particular reason to use the time-optimized
algorithms from apt, make or dpkg to do the job.
--
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
Reply to: