FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 11-18-2011, 08:45 AM
Guillem Jover
 
Default Multiarch interfaces

Hi,

I've modified some of the dpkg multiarch interfaces in my WIP branch
on hadrons.org, given their current inadequacy. Here's two of them,
I'll be starting a different thread for other ones.

I've added support for virtual fields to dpkg-query, those are output
only fields that can map to specially formatted text or sub-values
of normal fields. They are currently prefixed with virt: as in
virt:Virtual-Field-Name. The reason for this is that otherwise
possibly legitimate fields would get shadowed and could never be
exposed even if they had been parsed correctly (through the arbitrary
arbs fields), losing meta-data, this affects the PackageSpec virtual
field; and while the field has changed name I'll probably rename
to something resembling the more usual field name form, like
virt:Package-Spec for example. (As a side effect of this I'll be merging
support I had laying around for virt:Summary and virt:Status-Abbrev, I
could also name the first virt:Short-Description but's more verbose
although probably more commonly understood in deb circles, or we could
even have both.)

The other interface change is related to the --foreign-architecture
option, the problem with it comes from the fact that the architectures
supported by the database are not configuration, they are state. This
shows up in several ways. When a front-end needs to load the list of
architectures, it needs to get someone to parse dpkg.cfg files, this
is currently done by dpkg itself, and the list can be retrieved with
--print-foreign-architectures, the problem comes when wanting a
front-end to load them through libdpkg. Making the latter have to
execute dpkg --print-foreign-architectures would be suboptimal, and
making libdpkg have to load dpkg.cfg would be distasteful. Another
issue is that if the list of foreign architectures is on the
configuration files it makes it slightly more tricky to cross-grade
dpkg, and it makes it fairly easy to accidentally remove architectures
required by the database. I've fixed all this by replacing the
--foreign-architecture option with two new commands --add-architecture
and --del-architecture which will perform sanity checks and store and
load the architecture list (including the native arch) in an internal
db file under /var/lib/dpkg. (I'll probably rename --del-architecture
to something like --remove-architecture before pushing, to match the
convention in the rest of the dpkg CLI).

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111118094506.GA7073@gaara.hadrons.org">http://lists.debian.org/20111118094506.GA7073@gaara.hadrons.org
 
Old 11-18-2011, 10:01 AM
Raphael Hertzog
 
Default Multiarch interfaces

Hi,

On Fri, 18 Nov 2011, Guillem Jover wrote:
> I've added support for virtual fields to dpkg-query, those are output
> only fields that can map to specially formatted text or sub-values
> of normal fields. They are currently prefixed with «virt:» as in
> «virt:Virtual-Field-Name». The reason for this is that otherwise
> possibly legitimate fields would get shadowed and could never be
> exposed even if they had been parsed correctly (through the arbitrary
> arbs fields), losing meta-data, this affects the PackageSpec virtual
> field; and while the field has changed name I'll probably rename
> to something resembling the more usual field name form, like
> virt:Package-Spec for example. (As a side effect of this I'll be merging
> support I had laying around for virt:Summary and virt:Status-Abbrev, I
> could also name the first virt:Short-Description but's more verbose
> although probably more commonly understood in deb circles, or we could
> even have both.)

I already noticed this, I agree it's cleaner and this change will not
break anything AFAIK (only debsums tried to use that field, but has
fallback code if the field doesn't exist, I filed a bug so that they
remember to update the code once we have the final implementation in
place).

> Another issue is that if the list of foreign architectures is on the
> configuration files it makes it slightly more tricky to cross-grade
> dpkg

I don't follow you here. What's the problematic scenario?

> I've fixed all this by replacing the --foreign-architecture option with
> two new commands --add-architecture and --del-architecture which will
> perform sanity checks and store and load the architecture list
> (including the native arch) in an internal db file under /var/lib/dpkg.

This look ok to me too. --print-foreign-architectures must stay of course,
APT already relies on this interface.

Ubuntu will have to come up with a small transition strategy since they
modified dpkg to provide a supplementary configuration file precisely
to auto-enable i386 on amd64.

Maybe we could have a "multiarch-config" binary package provided by
dpkg that only provides a debconf interface to enable/disable
supplementary architectures. And the default answer could be changed
for each vendor/architecture combination.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111118110157.GA4596@rivendell.home.ouaza.com">ht tp://lists.debian.org/20111118110157.GA4596@rivendell.home.ouaza.com
 
Old 11-18-2011, 05:00 PM
Guillem Jover
 
Default Multiarch interfaces

On Fri, 2011-11-18 at 12:01:57 +0100, Raphael Hertzog wrote:
> On Fri, 18 Nov 2011, Guillem Jover wrote:
> > Another issue is that if the list of foreign architectures is on the
> > configuration files it makes it slightly more tricky to cross-grade
> > dpkg
>
> I don't follow you here. What's the problematic scenario?

dpkg built for amd64 (native), i386 (foreign arch) configured in
say /etc/dpkg.cfg.d/arch, several i386 packages installed. When one
cross-grades dpkg itself from amd64 to i386, suddenly all amd64
packages would be force-architecture worthy and as such broken for
any multi-arch enabled front-end.

With the new db, dpkg implicitly adds the native arch to the file (not
tagging it specially), and any additional foreign arch is added too.
So in the previous case the file starts with amd64, the user or another
package adds i386 through --add-architecture. When cross-grading dpkg
the file has both, and knows which one is the native one, based on the
internal knowdlege of what it was itself built for, so no
inconsistencies.

> > I've fixed all this by replacing the --foreign-architecture option with
> > two new commands --add-architecture and --del-architecture which will
> > perform sanity checks and store and load the architecture list
> > (including the native arch) in an internal db file under /var/lib/dpkg.
>
> This look ok to me too. --print-foreign-architectures must stay of course,
> APT already relies on this interface.

Well it should stay because it makes sense, not because there's
already users of an option not present upstream.

> Ubuntu will have to come up with a small transition strategy since they
> modified dpkg to provide a supplementary configuration file precisely
> to auto-enable i386 on amd64.

Yes, that's for them to cope with.

> Maybe we could have a "multiarch-config" binary package provided by
> dpkg that only provides a debconf interface to enable/disable
> supplementary architectures. And the default answer could be changed
> for each vendor/architecture combination.

The thing possibly needed is a mapping from native arch to supplementary
arches, supported by specific CPUs (not just amd64-i386), say:

amd64 → i386
ia64 → hppa, i386
s380x → s380
mips ←→ mipsel
armhf → armel, arm
armel → arm
powerpcspe → powerpc
ppc64 → powerpc
etc.

The problem is that enabling additional arches might incur a cost to
the user even if they are not going to use those, if for example the
front-end automatically starts downloading Packages files for those
other arches.

Except for things like possibly firmware, which AFAIR there seemed to
be consensus should be kept as arch:all for now (otherwise they'd
require Packages file for lots of architectures), the rest require
run-time support from libc. The problem with adding the arch from
the libc package is that's a chicken and egg situation.

If it were to be decided to create a multiarch-config package, I don't
think dpkg should be providing such package, generating it from the
same place multiarch-support seems to make more sense. Shipping the
mapping table in dpkg might make some sense though. The problem is
when conflacting support with activation in the same interface.

Things like qemu could add additional architectures if they provide
transparent cpu emulation, but doing so automatically would incur the
same costs. Probably qemu would add it to such a mapping table for
example, as supported but not activated.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111118180009.GA13047@gaara.hadrons.org">http://lists.debian.org/20111118180009.GA13047@gaara.hadrons.org
 
Old 11-24-2011, 02:49 PM
Goswin von Brederlow
 
Default Multiarch interfaces

Guillem Jover <guillem@debian.org> writes:

> The other interface change is related to the --foreign-architecture
> option, the problem with it comes from the fact that the architectures
> supported by the database are not configuration, they are state. This
> shows up in several ways. When a front-end needs to load the list of
> architectures, it needs to get someone to parse dpkg.cfg files, this
> is currently done by dpkg itself, and the list can be retrieved with
> --print-foreign-architectures, the problem comes when wanting a
> front-end to load them through libdpkg. Making the latter have to
> execute dpkg --print-foreign-architectures would be suboptimal, and
> making libdpkg have to load dpkg.cfg would be distasteful. Another
> issue is that if the list of foreign architectures is on the
> configuration files it makes it slightly more tricky to cross-grade
> dpkg, and it makes it fairly easy to accidentally remove architectures
> required by the database. I've fixed all this by replacing the
> --foreign-architecture option with two new commands --add-architecture
> and --del-architecture which will perform sanity checks and store and
> load the architecture list (including the native arch) in an internal
> db file under /var/lib/dpkg. (I'll probably rename --del-architecture
> to something like --remove-architecture before pushing, to match the
> convention in the rest of the dpkg CLI).
>
> regards,
> guillem

Please add support for more than just an on/off switch. An architecture
can have different "class":

1) first class architecture

The hardware can natively run this architecture. Anything can be
installed for it.

2) second class architecture

The hardware can not natively run this but there is an emulator
(e.g. qemu-armel) installed. Some things can not be installed for this
architecture and a first class architecture should be used by frontends
whenever possible. Worst case would be installing an armel /bin/sh on
amd64.

This probably is nothing dpkg has to care about but it should have the
information so frontends can get to it and do the right thing
(e.g. prefer first class archs, ask really loudly before replacing
anythign essential with a second class arch).

3) cross-compile architecture

The hardware may or may not be able to run this at all, natively or
emulated. Only Multi-Arch: foreign packages should be installable for
this architecture.

This is something dpkg could ensure but might also just be left to
frontends. But again there should be a central place to keep the
information.

MfG
Goswin



--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87aa7l5xm0.fsf@frosties.localnet">http://lists.debian.org/87aa7l5xm0.fsf@frosties.localnet
 
Old 11-24-2011, 03:30 PM
"John D. Hendrickson and Sara Darnell"
 
Default Multiarch interfaces

I like! I suggest getting one stable at a time, keeping goal in mind.


~ Please add support for more than just an on/off switch. An architecture ~



--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4ECE7119.6000802@cox.net">http://lists.debian.org/4ECE7119.6000802@cox.net
 
Old 11-25-2011, 08:57 PM
Steve Langasek
 
Default Multiarch interfaces

Hi Guillem,

On Fri, Nov 18, 2011 at 10:45:06AM +0100, Guillem Jover wrote:
> The other interface change is related to the --foreign-architecture
> option, the problem with it comes from the fact that the architectures
> supported by the database are not configuration, they are state. This
> shows up in several ways. When a front-end needs to load the list of
> architectures, it needs to get someone to parse dpkg.cfg files, this
> is currently done by dpkg itself, and the list can be retrieved with
> --print-foreign-architectures, the problem comes when wanting a
> front-end to load them through libdpkg. Making the latter have to
> execute «dpkg --print-foreign-architectures» would be suboptimal, and
> making libdpkg have to load dpkg.cfg would be distasteful. Another
> issue is that if the list of foreign architectures is on the
> configuration files it makes it slightly more tricky to cross-grade
> dpkg, and it makes it fairly easy to accidentally remove architectures
> required by the database. I've fixed all this by replacing the
> --foreign-architecture option with two new commands --add-architecture
> and --del-architecture which will perform sanity checks and store and
> load the architecture list (including the native arch) in an internal
> db file under /var/lib/dpkg. (I'll probably rename --del-architecture
> to something like --remove-architecture before pushing, to match the
> convention in the rest of the dpkg CLI).

Thanks, this makes sense to me.

On Fri, Nov 18, 2011 at 12:01:57PM +0100, Raphael Hertzog wrote:
> > I've fixed all this by replacing the --foreign-architecture option with
> > two new commands --add-architecture and --del-architecture which will
> > perform sanity checks and store and load the architecture list
> > (including the native arch) in an internal db file under /var/lib/dpkg.

> This look ok to me too. --print-foreign-architectures must stay of course,
> APT already relies on this interface.

> Ubuntu will have to come up with a small transition strategy since they
> modified dpkg to provide a supplementary configuration file precisely
> to auto-enable i386 on amd64.

Yep, that doesn't sound like a problem.

On Fri, Nov 18, 2011 at 07:00:09PM +0100, Guillem Jover wrote:

> > Maybe we could have a "multiarch-config" binary package provided by
> > dpkg that only provides a debconf interface to enable/disable
> > supplementary architectures. And the default answer could be changed
> > for each vendor/architecture combination.

> The thing possibly needed is a mapping from native arch to supplementary
> arches, supported by specific CPUs (not just amd64-i386), say:

> amd64 → i386
> ia64 → hppa, i386
> s380x → s380
> mips ←→ mipsel
> armhf → armel, arm
> armel → arm
> powerpcspe → powerpc
> ppc64 → powerpc
> etc.

> Except for things like possibly firmware, which AFAIR there seemed to
> be consensus should be kept as arch:all for now (otherwise they'd
> require Packages file for lots of architectures), the rest require
> run-time support from libc. The problem with adding the arch from
> the libc package is that's a chicken and egg situation.

What libc support do you mean? All per-architecture executables should have
dependencies on the libc package for their arch anyway, so I don't see how
libc support really enters into this.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 11-27-2011, 10:38 PM
Guillem Jover
 
Default Multiarch interfaces

On Fri, 2011-11-25 at 15:57:59 -0600, Steve Langasek wrote:
> On Fri, Nov 18, 2011 at 10:45:06AM +0100, Guillem Jover wrote:
> > > Maybe we could have a "multiarch-config" binary package provided by
> > > dpkg that only provides a debconf interface to enable/disable
> > > supplementary architectures. And the default answer could be changed
> > > for each vendor/architecture combination.
>
> > The thing possibly needed is a mapping from native arch to supplementary
> > arches, supported by specific CPUs (not just amd64-i386), say:
>
> > amd64 → i386
> > ia64 → hppa, i386
> > s380x → s380
> > mips ←→ mipsel
> > armhf → armel, arm
> > armel → arm
> > powerpcspe → powerpc
> > ppc64 → powerpc
> > etc.
>
> > Except for things like possibly firmware, which AFAIR there seemed to
> > be consensus should be kept as arch:all for now (otherwise they'd
> > require Packages file for lots of architectures), the rest require
> > run-time support from libc. The problem with adding the arch from
> > the libc package is that's a chicken and egg situation.
>
> What libc support do you mean? All per-architecture executables should have
> dependencies on the libc package for their arch anyway, so I don't see how
> libc support really enters into this.

Yes, I meant them needing the dynamic linker and libc.so. So if we are
on arch:amd64, want to install pkga:i386, and libc:i386 is the one
doing the dpkg --add-architecture i386, then apt will not be able to
nicely present the package to the user before the user has installed
it. Hope this clarifies.

There's also the quite exceptional case where a package is arch specific
but does not depend on libc, like libaio, which only provides syscall
stubs.

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111127233801.GC16825@gaara.hadrons.org">http://lists.debian.org/20111127233801.GC16825@gaara.hadrons.org
 
Old 11-28-2011, 03:55 AM
Steve Langasek
 
Default Multiarch interfaces

On Mon, Nov 28, 2011 at 12:38:01AM +0100, Guillem Jover wrote:
> > > Except for things like possibly firmware, which AFAIR there seemed to
> > > be consensus should be kept as arch:all for now (otherwise they'd
> > > require Packages file for lots of architectures), the rest require
> > > run-time support from libc. The problem with adding the arch from
> > > the libc package is that's a chicken and egg situation.

> > What libc support do you mean? All per-architecture executables should have
> > dependencies on the libc package for their arch anyway, so I don't see how
> > libc support really enters into this.

> Yes, I meant them needing the dynamic linker and libc.so. So if we are
> on arch:amd64, want to install pkga:i386, and libc:i386 is the one
> doing the dpkg --add-architecture i386, then apt will not be able to
> nicely present the package to the user before the user has installed
> it. Hope this clarifies.

Oh, ok. I had understood "the rest of the architectures" rather than "the
rest of the packages" - thanks for the clarification. Yes, it would be a
bootstrapping problem to have libc registering the architecture with dpkg.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 11-28-2011, 08:33 AM
Goswin von Brederlow
 
Default Multiarch interfaces

Steve Langasek <vorlon@debian.org> writes:

> On Mon, Nov 28, 2011 at 12:38:01AM +0100, Guillem Jover wrote:
>> > > Except for things like possibly firmware, which AFAIR there seemed to
>> > > be consensus should be kept as arch:all for now (otherwise they'd
>> > > require Packages file for lots of architectures), the rest require
>> > > run-time support from libc. The problem with adding the arch from
>> > > the libc package is that's a chicken and egg situation.
>
>> > What libc support do you mean? All per-architecture executables should have
>> > dependencies on the libc package for their arch anyway, so I don't see how
>> > libc support really enters into this.
>
>> Yes, I meant them needing the dynamic linker and libc.so. So if we are
>> on arch:amd64, want to install pkga:i386, and libc:i386 is the one
>> doing the dpkg --add-architecture i386, then apt will not be able to
>> nicely present the package to the user before the user has installed
>> it. Hope this clarifies.
>
> Oh, ok. I had understood "the rest of the architectures" rather than "the
> rest of the packages" - thanks for the clarification. Yes, it would be a
> bootstrapping problem to have libc registering the architecture with dpkg.

Wouldn't it make more sense to highjack the multiarch-support (the
native one) package and have it ask a debconf question wether to
activate i386 on amd64 and amd64 on i386 and so on?

And qemu-armel would add armel support, not the libc:armel.

I don't see how the libc would be the right place for this. That just
gives you a chicken&egg problem.

MfG
Goswin


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

Thread Tools




All times are GMT. The time now is 09:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org