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

Re: Priorities overrides? Extra?



Andrey Rahmatullin <wrar@debian.org> writes:
> Note that you mix two completely different questions in your email.
>
> On Sun, Apr 10, 2016 at 02:22:54PM +0200, Ole Streicher wrote:
>> http://ftp.debian.org/debian/indices/override.stretch.main.gz
>> 
>> I find there more than 48.000 overrides; which means that almost *all*
>> packages are overridden.
>> 
>> What is the reason for that? I would expect that overriding is something
>> exceptional, but not the common way to set the priority?
> I guess that's an implementation detail of the archive software. Priority
> fields in the packages are only informational, that's all.

Question is wich information they cover. For me, "optional" means:
conflict free by policy.

> 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. For a field that
is -- as you said -- pure informational (and where the wrong setting
could be mentioned just by filing a bug).

> Yet another one is the bad policy wording about "likely to be useful
> if you already know what they are" (see #660249 about dropping that).

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.

However, it is an dependency of other programs, and they are *not*
special anymore. But by policy they would be required to be "extra" as
well.

> 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 would just like to see how
we can get back to get it useful and how we can people take it seriously.

My problem here is that, according to the policy, no "extra" programs
should be installed by the Debian installer -- 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? I could create bugs
for all affected packages (of the blends, and their dependencies), which
would end up in maybe 1000 bug reports (or commits, if they are team
maintained). However, at some point I would have to ask the ftp-masters
to change all these priorities, and I am not sure whether they are too
happy with it.

Best regards

Ole


Reply to: