On Sun, Apr 10, 2016 at 08:34:18PM +0200, Ole Streicher wrote: > > 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. You are still mixing two completely separate things. > > 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 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. > > 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. You should use "optional" for such packages. > > 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. > My problem here is that, according to the policy, no "extra" programs > should be installed by the Debian installer I don't think the policy says or means anything about 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? See? That's why your package should be priority: optional. > 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. 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. -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature