Re: Priorities overrides? Extra?
Andrey Rahmatullin <wrar@debian.org> writes:
> On Sun, Apr 10, 2016 at 08:34:18PM +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?
>> > One of the other reasons is dh_make(1). It was broken by a stupid (IMO)
>> > #373603 in 2006 and fixed back by #706164 in 2013.
>>
>> Yes; this is the reason why I had it in some of my first packages, from
>> where it was copied and pasted to other new packages.
>>
>> The problem is that I cannot set it back on my own. I have to ask
>> ftp-master and put them more load on their shoulders.
> 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.
>> 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?
>> 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.
>> > 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".
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? If they
were all priority "optional" (and we would file/fix the policy
violations), we could.
Usage by the Debian installer/tasksel is IMO one of the ue cases for the
distinction between "extra" and "optional": If a package is "extra", it
has either the risk of introducing a package conflict, or it is so
special that there is no reason to be installed by a common task.
>> -- either since they are really too special, or since they may have
>> conflicts. So, to get the Debian Blends into the installer, what should
>> I do?
> See? That's why your package should be priority: optional.
.... as thousands other packages. I'd have no problems to file a bug
report for each of these against ftp-masters, but I would like to hear
opinions about that first.
> 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.
Best regards
Ole
Reply to: