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

Re: apt-pinning information



On Thu, Jan 11, 2018 at 02:33:03PM +0900, Osamu Aoki wrote:
> > i.e. if you want to match all packages of any architecture, *:* is
> > OK just like *:any, but * alone is not.
> 
> "*" alone seems to be treated as "*:native" (??and  "*:all"??)
> architectures.  (apt-pkg/cacheset.cc)

This code isn't involved in preferences parsing directly. Anyhow,
a simple test would have shown that the premise of the bugreport is
wrong, e.g.

| Package: *
| Pin: release n=experimental
| Pin-Priority: 100

ALL packages (regardless of architecture) from experimental get pinned
to 100. This is what the manpage calls a "generic-form". This is the
same behaviour we had before and after MultiArch. Adapting documentation
for this is thus not needed. Especially not in the suggested form as
this will confuse users. If the first line is NOT "Package: *", even if
you write "Package: *:*" this is NOT the "generic-form" but the
"specific-form". The manpage seems pretty clear about that as well.

For example:
| Package: firefox
| Pin: release n=experimental
| Pin-Priority: 500

This one applies only to firefox:native (yes, this includes firefox:all,
but that is a technical detail no "normal" user should ever be concerned
with). Same if you write "firefox*".  Specific stanzas behave similar
to the commandline.  It would just be pointless to have "apt install
firefox*" try to install all firefox packages in all available
architectures as that is guaranteed to end in failure and it seems the
most sensible to have the same rules in preferences to not make this
more complicated.

(It is also backward compatible as someone with that pin coming from
single arch wouldn't have liked apt (or more realistically aptitude) to
suggest installing firefox:i386 on a amd64 in certain situations even if
perfectly legal)


> Other than these multiarch related syntax and regex syntax, I don't see
> "Obsoletes" mentioned in dependency documentation but I see it in the
> source.

Obsolete is obsolete. Or, well, never really was existing, at least not
in my time. It stems from a try to merge apt-rpm code. There is nothing
to document about it as a) its not working in apt and b) it isn't
working anywhere else (like dpkg) and perhaps most importantly c) it is
completely undefined what it would mean in Debian. Also, it has no
relation whatsoever to pinning, so not sure why it came up here…


> Someone knowledgeable needs to update:
>  doc/apt_preferences.5.xml
>  doc/guide.dbk

Make that doc/*.

Am I hopeful that this will happen anytime soon given the current team
size? No.

I just wrote three new manpages. One of those says "was undocumented for
years" (in the other two I didn't wrote it as they had at least a few
bits documented elsewhere before). The last manpage I wrote before that
has the same sentence. I am trying to write a few words about the things
I add/change, just like I try to add a testcase for it – but personally,
I think I am not particular good at writing documentation and what is
perhaps worse is that if I touch a documentation task it usually ends in
reworking the thing-to-be-documented. That "worked" with apt_auth.conf,
apt-transport-mirror & -tor, but isn't really ideal (at least from
a "get this documented soon and applicable to all apt versions
preferably" point of view).

So if you (or someone else) wants to work on it: Go a head, there is
noone stopping you & we will try to help as best we can. No point in
stomping your boots on the ground and demanding changes through.


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


Reply to: