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

Re: Conflicting packages not of extra priority.



On Fri, Feb 05, 1999 at 01:21:37PM -0500, Dale Scheetz wrote:
> Because from what you say, libc6 should have a priority of Extra, as it
> conflicts with several non-Extra packages, as do almost all of the other
> packages delivered by the glibc source.

Package: libc6
...
Conflicts: libc5 (<< 5.4.33-7), libpthread0 (<< 0.7-10), libstdc++2.8 (=
2.90.29-1), libstdc++2.9 (<< 2.91.59-2)

Of those, libc5 in slink is 5.4.46-1 (oldlibs), libpthread0 is 0.6-1
(oldlibs), libstdc++2.8 is 2.90.29-2 (oldlibs) and libstdc++2.9 is
2.91.60-4 (base). That leaves just one conflicting package in slink:
libpthread0, and yes, I think libpthread0 should be Priority: Extra
(IMHO, all the "oldlibs" packages should be).
 
We may do the same exercise with the remaining packages delivered by the
glibc source if you wish.

> No but your reading of the statement seems to imply that you wish only
> optional and above package conflicts to enforce the Extra priority. This
> implies that any package that conflicts with an Extra package _must_ be in
> one of the other priority groups.

I don't follow your reasoning. 

What we read there is: No conflicts between packages of priority > extra.
That means:

Package A conflicts with package B.
Packages A and B have priority > extra.
then
We must change the priority of package A or package B to extra. 

That doesn't imply:

Package A conflicts with package B
Package B has priority = extra
then
Package A must have priority != extra.

does it?

> When two pieces of software perform the exact same job to the extent that
> they must conflict with each other, there is no criterion for placing one
> package at a higher priority than the other. Debian is not in the business
> of making such decissions for our users. The availability of the two
> programs should be placed on an equal footing, allowing the user the
> freedom to decide which of the two is preferred.

I guess there are criteria, and we do are in that business. Else, why do
we have: exim (important), ssmtp (extra), zmailer (extra), smail (extra),
sendmail (extra), ... ? What about update-alternatives priorities?

If a user knows he wants smail instead of exim he can easily install
that one. If a user doesn't know which one he likes better, we suggest
him to use exim, by assigning that package a higher priority. That
improves the "user-friendliness" of our system, without limiting the
freedom of our power-users.

> No, it doesn't. It says that packages that do so, may be placed in Extra.
> It does not say that packages that behave this way "must" be placed in
> that priority.

IIRC, Ian Jackson (the one who wrote that paragraph) agrees with the
"must" meaning.
 
> If the packages each conflict with the other, there is no logic, provided
> by your definition, for choosing which of the two should change priority.

Of course not. The policy manual can't say us which of exim, smail,
sendmail, zmailer, etc... must be priority extra. That's something we
choose ourselves (basing our decision in some "technical" criteria).
 
--
Enrique Zanardi					   ezanardi@ull.es


Reply to: