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 01-31-2011, 09:56 AM
Raphael Hertzog
 
Default Need feedback on dpkg's behaviour with multiarch packages

Hi,

with Guillem we're wondering how we should "interpret" an unqualified
"foo" when foo is a multi-arch package. For the sake of the example,
we'll use "libsame" a package which is Multi-Arch: same (and thus
coinstallable) and "pkg-foreign" a package which is Multi-Arch:
foreign/allowed (and we assume we actually have installed a foreign
instance on this package on our system).

How to interpret the input
--------------------------

Consider that we have installed libsame:i386 and libsame:amd64 on the
system (which is an i386 system).

The user types "dpkg -r libsame". What do you expect dpkg to do?

1/ Assume libsame == libsame:native and remove libsame:i386 only.
2/ Assume he meant all instances of libsame, and remove libsame:i386 and
libsame:amd64.
3/ Fail because the user has not been specific enough.

Then ask yourself the same question but this time only libsame:i386 is
installed. Now you have:

1/ Idem to above.
2/ Assume he meant all instances of libsame, and remove libsame:i386.
3/ Even if the user has not specified the architecture for this multiarch
package, there's only arch installed, so assume it's the one that he wants
to remove.
4/ Fail because we really can't be sure what he wanted to remove.

Then ask yourself the same question but this time only libsame:amd64 is
installed. Now you have:

1/ Assume libsame == libsame:native, which is not installed, so we do
nothing.
2/ Assume he meant all instances of libsame, and remove libsame:amd64.
3/ Even if the user has not specified the architecture for this multiarch
package, there's only arch installed, so assume it's the one that he wants
to remove. Remove libsame:amd64.
4/ Fail because we really can't be sure what he wanted to remove.


Start again the analysis now considering that the users types "dpkg
--status libsame" or "dpkg --listfiles libsame". This time the output
will look like multiple packages were queried while the user gave only
one argument in the input. It has thus the potential to break scripts.

Which of the 4 interpretations above should apply in this case ?


I'll try to cover the pros/cons of the various interpretations:

* Assume foo == foo:native.
+ Simple and straightforward mapping rule.
+ Can be applied in all contexts (including dpkg --set-selections).
+ Won't break scripts.
- Requires a new syntax (foo:*) to say "all instances of this package".
- Might surprise the user with a "package not installed" error when he
wants to refer to a foreign package and he forgets to precise the
architecture name.

* Assume foo == foo:*.
+ Simple and straightforward mapping rule.
+ Matches the "Do What I Mean" logic more often.
+ Do not need a new syntax to say "all instances of this package".
- Has the potential to break scripts due to dpkg --status/--listfiles
returning multiple answers for a single argument.
- Can't be assumed in dpkg --set-selections.

* Assume foo == foo:whatever provided that whatever is unique (resolve
when there's no ambiguitiy, otherwise fail).
+ Has a feeling of "Do What I Mean" more often than not.
- Has the potential to break scripts because it will fail with
co-installable M-A packages.
- Mapping rule depends on the context of the installed system. Thus it
might mean something different on different systems.
- Requires a new syntax (foo:*) to say "all instances of this package".
- Can't be used in dpkg --set-selections.

Based on this analysis, I was leaning towards "Assume foo == foo:native"
but Guillem would prefer "Assume foo == foo:*" so we'd like some external
feedback.

How to print the package names
------------------------------

In the same vein, we should decide how dpkg is going to print package
names in various contexts. Obviously the decision above will have an
impact here... because scripts might retrieve package names from
the output of dpkg and feed it back in the input of other dpkg commands.

My suggestion is along those lines:
- any package of foreign arch should always have its architecture appended
to its package name
- package of native arch which are multi-arch same should have the
architecture appended only if there are other instances of the same
package installed
- other packages do not need the arch qualifier

Does that seem reasonable enough?

If we decide "assume foo == foo:*" maybe change the second rule to always
print the architecture name for a multi-arch same package, although
possibly with an alias telling that we're referring to the package of
native architecture, whatever that is (see open question below).

For reference, the various contexts in which package names are printed by
dpkg are:
- the status logs (and thus also in the file descriptor passed with --status-fd)
- output of "dpkg -l"
- output of "dpkg -S"
- output of "dpkg-query -W"
- output of "dpkg --get-selections"
- output of "dpkg --audit"
- output of "dpkg --yet-to-unpack"
- lots of messages everywhere (user messages on screen, error messages,
debug messages, etc.)

One more question:
- shall we invent a "foo:native" syntax that we can output instead of
"foo:i386" in the output of dpkg --get-selections so that transferring
the selection over to another computer running another architecture
will still work ?

I have included deity@lists.debian.org because APT developers have
certainly taken some decision on this topic when they have implemented
multi-arch support in APT. Dear APT developers, your input as frontend
developer is very welcome on those topics.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110131105625.GA7015@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110131105625.GA7015@rivendell.home.ouaza.com
 
Old 02-01-2011, 08:39 AM
David Kalnischkies
 
Default Need feedback on dpkg's behaviour with multiarch packages

On Mon, Jan 31, 2011 at 11:56, Raphael Hertzog <hertzog@debian.org> wrote:
> I have included deity@lists.debian.org because APT developers have
> certainly taken some decision on this topic when they have implemented
> multi-arch support in APT. Dear APT developers, your input as frontend
> developer is very welcome on those topics.

I fear i am of no help in this regard as APT has superior knowledge:
APT::Architectures defines which Architecture data should be downloaded
and in which order giving Architectures a preference, so the current
implementation simply assumes if no specific architecture is requested
that the most preferred Architecture is meant (currently its completely
dependent on the order of this list, but i kind of like the idea to look first
at the pinning values to have a finer control).

This was chosen simple because most people will not care which
architecture the package they want to install is built for.
They simply want the program inside installed, regardless of arch
and version (otherwise they had been more specific).


The remove follows for consistence the same rules which leads to
interesting cases like a failing 'apt-get remove foo' on an amd64 machine
with i386 and amd64 available but i386 installed as APT assumes
that foo:amd64 was meant -- but the install request in this situation
was 'apt-get install foo:i386' so its at least consistent in its small world.

If we would go for a 'what the user meant was foo:installed-arch' we
would need to choose for 'same' libraries or removing both which is
kind of awkward if your install request was 'apt-get install libsame'
5 minutes ago and now you need to get right of the package with
'apt-get remove libsame:amd64' because libsame:i386 is installed
for ages now on your computer because of foo:i386.


So, all in all, i would vote for no arch = native - simply because you have
similar problems not only for remove and purge but for example also
on --configure libsame after an unpack request for :i386 and :amd64
was done. Which one do you want to configure now:
- both (in which order?)
- the native one (:amd64)
- fail as not specific enough
Does this change if the :amd64 one is already configured?
- (assume :amd64 as :native) fail as already configured
- choose :i386 (as :amd64 as native is already) and configure it
- choose both, ignore :amd64 and configure :i386
- choose both, fail :amd64 as already configured (and maybe configure i386)
- fail as not specific enough


Best regards

David Kalnischkies


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTinr76wqjxBpcf6drLVmF_T=XqNZFpbSh6ZDX01W@mail .gmail.com">http://lists.debian.org/AANLkTinr76wqjxBpcf6drLVmF_T=XqNZFpbSh6ZDX01W@mail .gmail.com
 
Old 02-01-2011, 10:11 AM
Tollef Fog Heen
 
Default Need feedback on dpkg's behaviour with multiarch packages

]] Raphael Hertzog

Hi,

| * Assume foo == foo:native.
| + Simple and straightforward mapping rule.
| + Can be applied in all contexts (including dpkg --set-selections).
| + Won't break scripts.
| - Requires a new syntax (foo:*) to say "all instances of this package".
| - Might surprise the user with a "package not installed" error when he
| wants to refer to a foreign package and he forgets to precise the
| architecture name.

I think this is the most sensible option. Sure, it's not very DWIM, but
it's the most conservative one. The new syntax is a bit annoying, but
that's life (maybe allow foo: as an alias for foo:*, since that
means less quoting in shells?). As for error messages, we can add logic
that looks for footherarch if foo:same doesn't match, or at least add
that bit to the error message.

| My suggestion is along those lines:
| - any package of foreign arch should always have its architecture appended
| to its package name
| - package of native arch which are multi-arch same should have the
| architecture appended only if there are other instances of the same
| package installed
| - other packages do not need the arch qualifier
|
| Does that seem reasonable enough?

You should be able to use the output as input, which I think this
allows. I'm leaning slightly towards making it output foo:native as
just foo, but I don't have a strong preference.

I think the real question is: Do we want to end up with foo:$arch being
the preferred name everywhere or not? We should print it in the form we
want to be the preferred one.

| One more question:
| - shall we invent a "foo:native" syntax that we can output instead of
| "foo:i386" in the output of dpkg --get-selections so that transferring
| the selection over to another computer running another architecture
| will still work ?

I think using the string native as a magic alias for what arch this is
on would be useful, yes. I'm not convinced it should be used in output
by default, it's trivial to use sed to change it, after all.

Regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87fws880xb.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87fws880xb.fsf@qurzaw.varnish-software.com
 
Old 02-01-2011, 07:31 PM
Raphael Hertzog
 
Default Need feedback on dpkg's behaviour with multiarch packages

Hi David,

thanks for your answer.

On Tue, 01 Feb 2011, David Kalnischkies wrote:
> If we would go for a 'what the user meant was foo:installed-arch' we
> would need to choose for 'same' libraries or removing both which is
> kind of awkward if your install request was 'apt-get install libsame'
> 5 minutes ago and now you need to get right of the package with
> 'apt-get remove libsame:amd64' because libsame:i386 is installed
> for ages now on your computer because of foo:i386.

Good point.

> So, all in all, i would vote for no arch = native - simply because you have
> similar problems not only for remove and purge but for example also
> on --configure libsame after an unpack request for :i386 and :amd64
> was done. Which one do you want to configure now:
> - both (in which order?)
> - the native one (:amd64)
> - fail as not specific enough

I don't see why this case is more problematic/different than --remove?

> Does this change if the :amd64 one is already configured?
> - (assume :amd64 as :native) fail as already configured
> - choose :i386 (as :amd64 as native is already) and configure it
> - choose both, ignore :amd64 and configure :i386
> - choose both, fail :amd64 as already configured (and maybe configure i386)
> - fail as not specific enough

So your point is that the matching logic could also be different
for --configure if we want to apply a "Do What I Mean" logic everywhere.

Thanks.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110201203128.GE30280@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110201203128.GE30280@rivendell.home.ouaza.com
 
Old 02-16-2011, 02:55 PM
Goswin von Brederlow
 
Default Need feedback on dpkg's behaviour with multiarch packages

Raphael Hertzog <hertzog@debian.org> writes:

> Hi,
>
> with Guillem we're wondering how we should "interpret" an unqualified
> "foo" when foo is a multi-arch package. For the sake of the example,
> we'll use "libsame" a package which is Multi-Arch: same (and thus
> coinstallable) and "pkg-foreign" a package which is Multi-Arch:
> foreign/allowed (and we assume we actually have installed a foreign
> instance on this package on our system).
>
> How to interpret the input
> --------------------------
>
> Consider that we have installed libsame:i386 and libsame:amd64 on the
> system (which is an i386 system).
>
> The user types "dpkg -r libsame". What do you expect dpkg to do?
>
> 1/ Assume libsame == libsame:native and remove libsame:i386 only.
> 2/ Assume he meant all instances of libsame, and remove libsame:i386 and
> libsame:amd64.
> 3/ Fail because the user has not been specific enough.

I think the behaviour should be to match how you print package names. So
lets skip to that.

> How to print the package names
> ------------------------------
>
> In the same vein, we should decide how dpkg is going to print package
> names in various contexts. Obviously the decision above will have an
> impact here... because scripts might retrieve package names from
> the output of dpkg and feed it back in the input of other dpkg commands.
>
> My suggestion is along those lines:
> - any package of foreign arch should always have its architecture appended
> to its package name
> - package of native arch which are multi-arch same should have the
> architecture appended only if there are other instances of the same
> package installed
> - other packages do not need the arch qualifier
>
> Does that seem reasonable enough?

Lets first consider an existing systems. The output of packages is
without the architecture. In the future many systems will still have
just one architecture installed despite having multiarch packages
available. The conservative approach is to sill not add the architecture
to the output.

On the other hand for multiarch systems there must be a way to
differentiate the library packages from different architectures. There
can be many architectures but only one native one. Since we can only
allow one architecture to not add the architecture to the name and still
be unique the foreign archs must add the architecture.

If we show native packages without the architecture added at all times
then the output is the same for old systems, new systems with only
native packages and new systems with foreign packages. Installing
libfoo:amd64 does not change that libfoo means libfoo:i386 and that
libfoo:i386 is displayed as libfoo. I think that is the most consistent
way. Having the name change depending on what else is installed would be
confusing.

As a special case I would allow foo to match foo:amd64 if foo is not
multi-arch same package for the purpose of specifying packages but still
display the architecture on output.

> One more question:
> - shall we invent a "foo:native" syntax that we can output instead of
> "foo:i386" in the output of dpkg --get-selections so that transferring
> the selection over to another computer running another architecture
> will still work ?

Using plain "foo" avoids this issue and keeps things compatible between
old and new systems. You can then transfere your selections from squeeze
to wheezy and back.

> I have included deity@lists.debian.org because APT developers have
> certainly taken some decision on this topic when they have implemented
> multi-arch support in APT. Dear APT developers, your input as frontend
> developer is very welcome on those topics.

MfG
Goswin


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

Thread Tools




All times are GMT. The time now is 10:05 AM.

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