Subject: apt/preferences: need for pinning a given (set of) package per release
Date: Sun, 19 Oct 2003 15:45:34 +0200
Package: apt
Version: 0.5.14
Severity: wishlist
Currently, as documented in the sid manpage, one can only pin a single
package per "version", or all packages (via "*") per "release".
It would be useful to pin a single package per "release" as well, since:
1. one possibly does not want to bother what the package version is
2. pinning a version uwing a wildcard may not be adequate, as
examplified by the openssh major upgrade during the potato
maintainance cycle
-- Package-specific info:
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux bylbo 2.4.21-k6+preempt #1 jeu jui 10 10:51:00 CEST 2003 i586
Locale: LANG=français, LC_CTYPE=français
Versions of packages apt depends on:
ii libc6 2.3.2-8 GNU C Library: Shared libraries an
ii libgcc1 1:3.3.2-1 GCC support library
ii libstdc++5 1:3.3.2-1 The GNU Standard C++ Library v3
-- no debconf information
--
Yann Dirson <[email protected]> | Why make M$-Bill richer & richer ?
Debian-related: <[email protected]> | Support Debian GNU/Linux:
Pro: <[email protected]> | Freedom, Power, Stability, Gratuity
http://ydirson.free.fr/ | Check <http://www.debian.org/>
Subject: Re: Bug#216682: apt/preferences: need for pinning a given (set of) package per release
Date: Mon, 20 Oct 2003 12:29:47 -0400
On Sun, Oct 19, 2003 at 03:45:34PM +0200, Yann Dirson wrote:
> Currently, as documented in the sid manpage, one can only pin a single
> package per "version", or all packages (via "*") per "release".
>
> It would be useful to pin a single package per "release" as well, since:
>
> 1. one possibly does not want to bother what the package version is
>
> 2. pinning a version uwing a wildcard may not be adequate, as
> examplified by the openssh major upgrade during the potato
> maintainance cycle
The man page does not say this; that's just what the two examples look like.
Pinning a single package by release works fine.
--
- mdz
Subject: Re: Bug#216682: apt/preferences: need for pinning a given (set of) package per release
Date: Sun, 19 Oct 2003 21:53:41 +0200
retite 216682 apt_preferences.5 needs clarification on the syntax
reopen 216682
thanks
On Mon, Oct 20, 2003 at 12:29:47PM -0400, Matt Zimmerman wrote:
> On Sun, Oct 19, 2003 at 03:45:34PM +0200, Yann Dirson wrote:
>
> > Currently, as documented in the sid manpage, one can only pin a single
> > package per "version", or all packages (via "*") per "release".
> >
> > It would be useful to pin a single package per "release" as well, since:
> >
> > 1. one possibly does not want to bother what the package version is
> >
> > 2. pinning a version uwing a wildcard may not be adequate, as
> > examplified by the openssh major upgrade during the potato
> > maintainance cycle
>
> The man page does not say this; that's just what the two examples look like.
> Pinning a single package by release works fine.
(Ah, the fact I'm dealing with essential packages may have warped my
evaluation of the situation somehow)
However, it does say:
The specific form assigns a priority (a "Pin-Priority") to a
specified package and specified version or version range.
And:
The general form assigns a priority to all of the package versions in
a given distribution (that is, to all the versions of packages that
are listed in a certain Release file) or to all of the package
versions coming from a particular Internet site, as identified by the
site's fully qualified domain name.
I think it could be made more clear then.
Does "specific/general" refer to the "single package name" vs. "*"
aspect of the example, or to the "version/release" keyword ? The fact
that examples does not allow to disambiguate seems annoying to me.
The fact there is an "origin" keyword as well would advocate for the
1st alternative. BTW, this "origin" keyword is not documented, apart
from being mentionned as existing and being different from "release
o=...". You may want to address this as well - I don't think it's
worth openning another bugreport ;)
--
Yann Dirson <[email protected]> | Why make M$-Bill richer & richer ?
Debian-related: <[email protected]> | Support Debian GNU/Linux:
Pro: <[email protected]> | Freedom, Power, Stability, Gratuity
http://ydirson.free.fr/ | Check <http://www.debian.org/>
Subject: Re: Bug#216682: apt/preferences: need for pinning a given (set of) package per release
Date: Mon, 20 Oct 2003 15:24:29 -0400
severity 216682 wishlist
retitle 216682 People still don't understand the preferences file
thanks
On Sun, Oct 19, 2003 at 09:53:41PM +0200, Yann Dirson wrote:
> On Mon, Oct 20, 2003 at 12:29:47PM -0400, Matt Zimmerman wrote:
> > The man page does not say this; that's just what the two examples look like.
> > Pinning a single package by release works fine.
>
> (Ah, the fact I'm dealing with essential packages may have warped my
> evaluation of the situation somehow)
>
> However, it does say:
>
> The specific form assigns a priority (a "Pin-Priority") to a
> specified package and specified version or version range.
>
> And:
>
> The general form assigns a priority to all of the package versions in
> a given distribution (that is, to all the versions of packages that
> are listed in a certain Release file) or to all of the package
> versions coming from a particular Internet site, as identified by the
> site's fully qualified domain name.
>
>
> I think it could be made more clear then.
>
> Does "specific/general" refer to the "single package name" vs. "*"
> aspect of the example, or to the "version/release" keyword ? The fact
> that examples does not allow to disambiguate seems annoying to me.
>
> The fact there is an "origin" keyword as well would advocate for the
> 1st alternative. BTW, this "origin" keyword is not documented, apart
> from being mentionned as existing and being different from "release
> o=...". You may want to address this as well - I don't think it's
> worth openning another bugreport ;)
If you think it is unclear, please submit a patch improving it. The text
under VERSIONING explains this to my satisfaction. This man page has
already been practically rewritten, and still people have difficulty with
it.
I personally think that the old VERSIONING text was clearer:
> One purpose of the preferences file is to let the user select which
> version of a package will be installed. This selection can be made in a
> number of ways that fall into three categories, version, release and
> origin.
>
> Selection by version [...]
>
> Selection by release [...]
>
> The final selection method is by origin [...]
But I think that in the end, this just isn't a simple concept, and people will
always have trouble with it.
When in doubt, try something and see if it works. If you had done that
rather than filing this bug report, it would have answered your question
more efficiently, and we would not be having this discussion.
--
- mdz
Subject: Re: Bug#216682: apt/preferences: need for pinning a given (set of) package per release
Date: Sun, 19 Oct 2003 22:34:47 +0200
On Mon, Oct 20, 2003 at 03:24:29PM -0400, Matt Zimmerman wrote:
> severity 216682 wishlist
> retitle 216682 People still don't understand the preferences file
> thanks
Sorry for further retitling, I did not see your answer at first :)
> On Sun, Oct 19, 2003 at 09:53:41PM +0200, Yann Dirson wrote:
> If you think it is unclear, please submit a patch improving it.
Hm, is it unfair to wait before fully understanding it first ? :)
> The text under VERSIONING explains this to my satisfaction. This
> man page has already been practically rewritten, and still people
> have difficulty with it.
Yes, there has been considerable improvements since the woody version,
and I don't intend to criticize you and others about that. However,
after practicing the use of the feature, I still do not fully
understand all details, and I'd like, firstly, to disambiguate things
in my mind, and, secondly, to find a way to make that more clear in
the manpage.
> I personally think that the old VERSIONING text was clearer:
>
> > One purpose of the preferences file is to let the user select which
> > version of a package will be installed. This selection can be made in a
> > number of ways that fall into three categories, version, release and
> > origin.
> >
> > Selection by version [...]
> >
> > Selection by release [...]
> >
> > The final selection method is by origin [...]
I'll re-read the old manpage as well, and will see if I can improve
the new one.
> But I think that in the end, this just isn't a simple concept, and people will
> always have trouble with it.
That's possible. But nonetheles, I think it is a great feature, and
we should make it as accessible as possible.
> When in doubt, try something and see if it works. If you had done that
> rather than filing this bug report, it would have answered your question
> more efficiently, and we would not be having this discussion.
I _have_ done that, but, unfortunately, with essential packages...
Regards,
--
Yann Dirson <[email protected]> | Why make M$-Bill richer & richer ?
Debian-related: <[email protected]> | Support Debian GNU/Linux:
Pro: <[email protected]> | Freedom, Power, Stability, Gratuity
http://ydirson.free.fr/ | Check <http://www.debian.org/>
Subject: Re: Bug#216682: apt/preferences: need for pinning a given (set of) package per release
Date: Mon, 20 Oct 2003 00:12:15 +0200
On Sun, Oct 19, 2003 at 10:34:47PM +0200, Yann Dirson wrote:
> after practicing the use of the feature, I still do not fully
> understand all details, and I'd like, firstly, to disambiguate things
> in my mind, and, secondly, to find a way to make that more clear in
> the manpage.
Let's summarize what I think I have understood, from both versions of
the doc, and from experimentation. Since most of this either
complements material in the manpage, or is simply not explained in the
manpage, I'd like to have your opinion on this before I start to work
on the real doc. This appears to me[composing-this-mail-instead-of-
taking-overdue-sleep-time] as summarizing the issues that puzzled
me[desperately-trying-to-make-this-work-in-real-life]. YMMV. Mine
too, especially on tomorrow, I suppose.
- there is a specific form (identified by a single package name) and a
general one (identified by "Package: *")
- the general one allows to assign a priority to the version of all
packages provided by a given (set of) repository(ies) (ie. a line from
sources.list), regardless of what this version is. The computed
priority can then be observed in "apt-cache policy" output on the
left of the relevant repository line.
- the specific one allows to assign a priority to a given (range of)
version(s) of a given package, based on various criteria (see below).
The computed priority can then be observed in "apt-cache policy"
output on the right of the matched package version, even when not
using the package version as criteria. Additionally, a possible
display bug in "apt-cache policy" causes the elected priority to get
displayed next to all other available versions.
- for a given package, only the last paragraph of the specific form is
read, all previous ones are ignored without notice. Because of this
the layout of "apt-cache policy" output seems strange, and this could
account for the above-mentionned "possible display-bug".
- FIXME: I did not experiment yet with equivalent combinations of the
general forms
- FIXME: given independant scores for the general and specific forms,
I suppose the candidate version is the one which has the best eligible
score in either slot ?
- There are 3 ways of selecting (pinning) the (range of) versions a
paragraph refers to: by release, by version, and by origin. A
paragraph of the general form can only use a "release" Pin, whereas a
paragraph of the specific form can use any Pin form.
(or maybe 'origin ""' is the only one accepted by the general form ?
I did not test this one, but it seems 'origin ftp.debian.org' was
ignored for the general form (unless I missed something else),
although it worked for the specific from)
(those 3 forms are adequately described in the old doc. The new doc
completely forgets to document "origin" pins, only mentions release
pins in the doc about the general case, and (correctly) only mentions
version pins in the doc about the specific case. I think those
issues are orthogonal enough to deserve being described separatedly.)
Regards,
--
Yann Dirson <[email protected]> | Why make M$-Bill richer & richer ?
Debian-related: <[email protected]> | Support Debian GNU/Linux:
Pro: <[email protected]> | Freedom, Power, Stability, Gratuity
http://ydirson.free.fr/ | Check <http://www.debian.org/>
Subject: Re: Bug#216682: apt/preferences: need for pinning a given (set of) package per release
Date: Mon, 20 Oct 2003 17:48:22 -0400
On Mon, Oct 20, 2003 at 12:12:15AM +0200, Yann Dirson wrote:
> - there is a specific form (identified by a single package name) and a
> general one (identified by "Package: *")
>
> - the general one allows to assign a priority to the version of all
> packages provided by a given (set of) repository(ies) (ie. a line from
> sources.list), regardless of what this version is. The computed
> priority can then be observed in "apt-cache policy" output on the
> left of the relevant repository line.
>
> - the specific one allows to assign a priority to a given (range of)
> version(s) of a given package, based on various criteria (see below).
> The computed priority can then be observed in "apt-cache policy"
> output on the right of the matched package version, even when not
> using the package version as criteria. Additionally, a possible
> display bug in "apt-cache policy" causes the elected priority to get
> displayed next to all other available versions.
I don't think I like this "general" vs. "specific" distinction. I'd rather
say something like:
Each stanza contains criteria used to match a set of packages and
versions, and preferences that should be applied to those packages.
Packages can be matched by name, or "*" can be used to match all packages.
Versions can be matched [describe the methods]...
The preferences which can be applied are [pins]...
Does that make sense?
> - for a given package, only the last paragraph of the specific form is
> read, all previous ones are ignored without notice. Because of this
> the layout of "apt-cache policy" output seems strange, and this could
> account for the above-mentionned "possible display-bug".
Is this true? I haven't checked the code. It seems more likely that it
simply overwrites existing data in those fields.
> - FIXME: I did not experiment yet with equivalent combinations of the
> general forms
What do you mean?
> - FIXME: given independant scores for the general and specific forms, I
> suppose the candidate version is the one which has the best eligible score
> in either slot ?
I'd have to look over the code to find out which match wins, if there is a
general rule. The old man page said this:
Each package may be pinned to a specific version and each Pack-
ages file has a priority for every package inside. The highest
priority assigned to a package is the one that is used.
> - There are 3 ways of selecting (pinning) the (range of) versions a
> paragraph refers to: by release, by version, and by origin. A
> paragraph of the general form can only use a "release" Pin, whereas a
> paragraph of the specific form can use any Pin form.
Pins for a specific package can use version, release or origin. Wildcard pins
("general form") can use release or origin (obviously an individual package
version doesn't make sense).
--
- mdz
Subject: Re: Bug#216682: apt/preferences: need for pinning a given (set of) package per release
Date: Mon, 20 Oct 2003 10:48:55 +0200
On Mon, Oct 20, 2003 at 05:48:22PM -0400, Matt Zimmerman wrote:
> I don't think I like this "general" vs. "specific" distinction. I'd rather
> say something like:
>
> Each stanza contains criteria used to match a set of packages and
> versions, and preferences that should be applied to those packages.
>
> Packages can be matched by name, or "*" can be used to match all packages.
>
> Versions can be matched [describe the methods]...
>
> The preferences which can be applied are [pins]...
>
> Does that make sense?
Hm, I'm not sure (should read the code ;), but there really seems to
be a distinction between those, since 'Package: *' causes the priority
to be assigned to the repository, as opposed to a set of packages.
> > - for a given package, only the last paragraph of the specific form is
> > read, all previous ones are ignored without notice. Because of this
> > the layout of "apt-cache policy" output seems strange, and this could
> > account for the above-mentionned "possible display-bug".
>
> Is this true? I haven't checked the code. It seems more likely that it
> simply overwrites existing data in those fields.
Possible - did not check either.
> > - FIXME: I did not experiment yet with equivalent combinations of the
> > general forms
>
> What do you mean?
That I still have to make the experiment of using several "general
form" stanzas applying to a given source and check what it does
exactly.
> > - FIXME: given independant scores for the general and specific forms, I
> > suppose the candidate version is the one which has the best eligible score
> > in either slot ?
>
> I'd have to look over the code to find out which match wins, if there is a
> general rule. The old man page said this:
>
> Each package may be pinned to a specific version and each Pack-
> ages file has a priority for every package inside. The highest
> priority assigned to a package is the one that is used.
That seems coherent.
> > - There are 3 ways of selecting (pinning) the (range of) versions a
> > paragraph refers to: by release, by version, and by origin. A
> > paragraph of the general form can only use a "release" Pin, whereas a
> > paragraph of the specific form can use any Pin form.
>
> Pins for a specific package can use version, release or origin. Wildcard pins
> ("general form") can use release or origin (obviously an individual package
> version doesn't make sense).
I'll have to re-check for the "general form" and origin, but I'm
pretty sure it didn't work in my test.
Regards,
--
Yann Dirson <[email protected]> | Why make M$-Bill richer & richer ?
Debian-related: <[email protected]> | Support Debian GNU/Linux:
Pro: <[email protected]> | Freedom, Power, Stability, Gratuity
http://ydirson.free.fr/ | Check <http://www.debian.org/>