popularity-contest broken with Multi-Arsch
 

Jonathan Nieder <jrnieder@gmail.com> writes:

> I ask because Bill's request makes a lot of sense in light of the
> explanation Russ gave on debian-devel of multiarch, where there is one
> package being installed and the list of architectures is just a detail
> of how it is installed.

It's important to note that Guillem raised very good objections to my
proposed model for handling architectures. (I didn't reply because I
didn't know enough about the internal data model of dpkg to be able to
discuss it meaningfully.)

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87r4w4zh8b.fsf@windlord.stanford.edu">http://lists.debian.org/87r4w4zh8b.fsf@windlord.stanford.edu

popularity-contest broken with Multi-Arsch
 

(dropping cc to bug#660712)
Russ Allbery wrote:

> (I didn't reply because I
> didn't know enough about the internal data model of dpkg to be able to
> discuss it meaningfully.)

Do you mean on disk or in memory?

If you mean on disk, everything is in /var/lib/dpkg. If you're
familiar with the /var/lib/dpkg/status file and
/var/lib/dpkg/<package>.* control files, then you know how to think
about packages the same way dpkg does. (Yes, diversions,
alternatives, triggers, and packages available for installation
through dselect are tracked separately, but they follow the same
model.)

Jonathan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120403210539.GA19858@burratino">http://lists.debian.org/20120403210539.GA19858@burratino

popularity-contest broken with Multi-Arsch
 

On Tue, 03 Apr 2012, Jonathan Nieder wrote:
> Forgive my ignorance: could you explain the rationale for the choice
> that was made for the meaning of "dpkg-query -L <package>" when
> <package> is multiarch:same?

The choice was not made for "dpkg -L" only, it was made in general for
all the package names that dpkg takes as input. And no I won't redo the
discussion, feel free to look back at the discussion of last december
IIRC.

But in the specific case of "dpkg -L", I can give you an example of why
it's a bad idea. You can have multiple arguments and each argument gives
a block of files: "dpkg -L foo bar baz" should give out 3 blocks, but
if "bar" is M-A: same with 2 arches, you get back 5 blocks and you can't
be sure of the mapping between packages and files (and in fact that's what
popcon does IIRC).

(Unless of course you wanted to merge the 2 blocks for bar, but then we're
needlessly complicating the code to create a fake view that doesn't match
dpkg's own view of the system)

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120403231434.GC1867@rivendell.home.ouaza.com">ht tp://lists.debian.org/20120403231434.GC1867@rivendell.home.ouaza.com

popularity-contest broken with Multi-Arsch
 

On Wed, Apr 04, 2012 at 01:14:34AM +0200, Raphael Hertzog wrote:
> On Tue, 03 Apr 2012, Jonathan Nieder wrote:
> > Forgive my ignorance: could you explain the rationale for the choice
> > that was made for the meaning of "dpkg-query -L <package>" when
> > <package> is multiarch:same?
>
> (Unless of course you wanted to merge the 2 blocks for bar, but then we're
> needlessly complicating the code to create a fake view that doesn't match
> dpkg's own view of the system)

Yes, this it what we need.

Cheers,
--
Bill. <ballombe@debian.org>

Imagine a large red swirl here.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120403232658.GD32630@yellowpig">http://lists.debian.org/20120403232658.GD32630@yellowpig

popularity-contest broken with Multi-Arsch
 

On Tue, 2012-04-03 at 20:29:46 +0200, Bill Allombert wrote:
> On Tue, Apr 03, 2012 at 03:27:47PM +0000, Thorsten Glaser wrote:
> > From: Cron Daemon <root@zigo.mirbsd.org>
> > To: root@zigo.mirbsd.org
> > Date: Tue, 3 Apr 2012 06:25:41 GMT
> > Subject: Cron <root@zigo> test -x /usr/sbin/anacron || ( cd / && run-parts
> > --report /etc/cron.daily )
> >
> > /etc/cron.daily/popularity-contest:
> > dpkg-query: error: --listfiles needs a valid package name but 'gcc-4.7-base' is not: ambiguous package name 'gcc-4.7-base' with more than one installed instance
>
> I think dpkg should just report the list of files in both packages to
> preserve the API.

The API is preserved as long as no multiarch is enabled. With
multiarch enabled any sane behaviour implies an interface change.
Outputting multiple paragraphs per package set would imply you need
to know which paragraph belongs to which package instance, it would
also produce duped content because you'd be requesting multiple times
the list for a package set for each instance present.

So, in the popularity-contest case, the program IMO needs to be adapted
anyway to support multiarch natively, as it stands currently (AFAICS),
the information submitted will not be accurate, as there's only a
single global architecture (the one from dpkg), but this is not really
representative of what the system is capable of (what the kernel can
run) or which architecture each package got installed for. dpkg has
always supported foreign architecture packages (although through a
force option), but with multiarch this is going to be even more
widespread.

There's also the cross-grading and mixed architectures case, where that
global architecture might be pretty meaningless, consider a system where
almost all packages are for amd64 but dpkg itself is for i386, or one
where packages are half-half different architectures, or even one where
the dpkg architecture differs from apt's architecture for example. I
think it's more relevant to know what the kernel can run, for example if
dpkg is i386 but the kernel is amd64, where the latter seems more
meaningful to me than the former.

So I'd say popcon needs to track the architecture for every and each
package instance, at which point requesting the specific information
for each package architecture instance should be pretty easy.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120404043624.GA9348@gaara.hadrons.org">http://lists.debian.org/20120404043624.GA9348@gaara.hadrons.org

popularity-contest broken with Multi-Arsch
 

Guillem Jover wrote:

> The API is preserved as long as no multiarch is enabled. With
> multiarch enabled any sane behaviour implies an interface change.
> Outputting multiple paragraphs per package set would imply you need
> to know which paragraph belongs to which package instance, it would
> also produce duped content because you'd be requesting multiple times
> the list for a package set for each instance present.

The above does not seem to take into account the request to use one
merged paragraph per package. Do you consider that an insane
behavior?


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120404054850.GC2460@burratino">http://lists.debian.org/20120404054850.GC2460@burratino

popularity-contest broken with Multi-Arsch
 

Jonathan Nieder dixit:

>The above does not seem to take into account the request to use one
>merged paragraph per package.

It will hide things like the fact that this machine has amd64,
i386 and m68k packages installed (which is something I’d definitively
want popcon to reflect).

bye,
//mirabilos
--
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.BSM.4.64L.1204041514260.19294@herc.mirbsd.org ">http://lists.debian.org/Pine.BSM.4.64L.1204041514260.19294@herc.mirbsd.org