On Sun, Apr 10, 2016 at 10:13:14PM +0200, Ole Streicher wrote: > >> Question is wich information they cover. For me, "optional" means: > >> conflict free by policy. > > You are still mixing two completely separate things. > Which? The existence of the override mechanism and the optional vs extra priority semantics.
> > Changing overrides is a normal procedure. > For 12.000 packages? Sure, these are less if I leave out oldlibs and > debug packages, but probably still a few thousands. We may do this by implementing #759260. > >> For a field that is -- as you said -- pure informational (and where the > >> wrong setting could be mentioned just by filing a bug). > > By saying "informational" I meant that the override value is what matters, > > not the field in the package. > So what is the field in the package for? Well, it sets the initial value of the override. I think ideally it should be the primary source of this information but we are not there yet and I don't know if something is done in that direction. > >> Sure. The problem arises f.e. with my package: it is really special, and > >> you would not like to install it unless you know what it is for. > > You should use "optional" for such packages. > Sure. As there are hundreds of other packages which are in the blends. Well, either you are considering them buggy or you aren't. In the former case you may want to fix those bug, in the latter one you don't do anything with it. > >> > See also #759260 for discussions about dropping extra completely. > >> > >> I would not drop it completely, since it provides the useful information > >> "may have conflicts with other packages". > > I'm not sure who would find this information useful. > > Note that according to the bug discussion this distinction was caused only > > by a requirement to be able to co-install all optional packages which is > > not useful at all. > > "Optional" packages are conflict free by policy. So, if we provide a few > default installations of Blends via tasksel, we can be sure that there > will be no conflict, as long as all tasks are Priority "optional". I'm not sure a task that installs a lot of arbitrarily chosen unrelated packages is useful either. > The problem is not to install *all* packages, but to be able to install > *every* package without the risk of having a conflict (not sure if my > englisch is good enoough here): how else can I make sure that if someone > chooses at installation time that he wants to have f.e. "Debian Astro" > installed, that none of the included packages have conflicts? I thought the task of making a distribution out of a bunch of packages involves more than just running a script that show which packages can be coinstalled. > > You can also behave like many packagers do: don't pretend that optional > > and extra priorities are different and that the policy (still) has > > different requirements about them. I don't see any downsides with that. > > As I wrote: The distinction is good for things that are done by first > install. Imagine some newcomer who selects the "Debian Games" pure blend > during the Debian installation and is then left alone with the > resolution of package conflicts. I'd call that a desaster. I don't know how do pure blemnds work but it's obvious to me that this situation with resolving conflicts should not be possible. But I'm not sure it's a good idea to just trust priorities for that. -- WBR, wRAR
