On Thu, Dec 06, 2007 at 09:36:58PM +0000, Neil Williams wrote:
brian m. carlson wrote: There is no functional or useful distinction between optional and extra, as far as I can see - what are you trying to retain?
If the distinction that is outlined in policy is followed, it is useful. It guarantees that all of optional is installable. It also guarantees that a useful system can be installed from packages that are priority optional or higher.
My principle query is why "optional" is not supposed to support Conflicts.
For the very reason that all of optional is supposed to be installable.
I think gpe-conf should be extra.1. That doesn't solve the conflict because gnome-control-center and kcontrol are still optional
Right. But then the conflicting package is extra, and gnome-control-center and kcontrol don't conflict with each other (they both used to be installed on my desktop). The only package here that conflicts is gpe-conf.
Packages which are extra can conflict with any package they want to, and packages which are optional or higher can conflict with packages which are extra. mail-transport-agent is a good example of the latter.
2. It would require migrating some 40 packages from optional to extra for - as far as I can tell - no good reason. Simpler just to ditch the Conflicts rule for optional and drop extra completely.
Those packages should always have been in extra from the start. The fact that a large number of packages are buggy does not necessitate a policy change. I have been using Debian since potato, and AFAICR, it has always been this way. This is nothing new.
Not true. GPE offers a desktop - just not a full Gnome desktop. There are plenty of alternative desktops in optional already. The full GPE environment is quite specialised but Debian does claim to the The Universal OS. Emdebian is concentrating on arm but any architecture can run GPE.
It could very well be used in that way. The way you described it implied that it was only suitable for embedded devices, which it apparently isn't. I apologize for my misunderstanding.
The difference is that the alternative desktops don't all conflict with one another. It is perfectly possible to have GNOME and KDE installed together, and I guess you could have those co-installed with GNUStep, XFCE4, and several other window managers as well. gpe-conf declares a conflicts because it doesn't work with other systems well; you said so yourself. Thus, gpe-conf is less important because it is less bulletproof; it is a poorer choice overall. Hence, it should either work better with other programs, or it should be in extra.
I'm saying that the majority of installations do not want orneed gpe-conf, so it should be extra.I don't follow the logic - nor do I see why that is different to the other desktop options that are not KDE or Gnome which are also intended for special or low resource environments.
The other environments don't conflict; gpe-conf (and the packages that depend on it) does. That's the difference. If GPE did not conflict with optional packages, it should be in optional. That's it.
I see no reason for any distinction between what is currently optional and what is currently 'extra'.
The rationale has always been that all of optional should be installable. That might not be something that many people want to do, but we should still support it, because that way we guarantee that any given subset of optional is also installable.
It's a tool for certain special environments. Note that this differs from tools like sparc-utils, that although they are specific to an architecture,That's a red herring, IMHO, because GPE is not specific to an architecture.
My point was that they are two different situations. Arch-specific packages might legitimately be of standard or even important priority on that architecture, but that's a distinction we can make, because they're only built on that architecture. To give another example, silo is priority important, because for sparc it is *the* bootloader. On amd64, it has very little utility, which is okay, because it isn't built there.
are very useful on those machines, and so might legitimately be priority optional or even standard.That seems to argue for a architecture-specific priority - a meta prority where is $arch eq "sparc" priority = required else priority = extra.
silo is useless on non-sparc archs, so it isn't built there. So, no, I don't think we need an architecture-specific priority.
-- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Attachment:
signature.asc
Description: Digital signature