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 12-05-2011, 07:55 AM
Guillem Jover
 
Default Multiarch interfaces: print foreign arches, pkgname I/O

Hi!


I've changed --print-foreign-architectures in pu/multiarch/master to
print an entry per line, which makes the print code trivial but more
importantly the parsers more natural and simple to write given line
based stream input functions, or shell commands reading from a pipe.

----

Package name output and input should be consistent and deterministic,
as such restrictions in one should apply to the other. One restriction
is related to cross-grading, and while it might seem like a corner-case,
not catering for it could cause chaos and a mess on the db when
cross-grading dpkg itself.

One of the issues with cross-grading is that the native architecture for
the running dpkg can be different than the one for the newly unpacked
dpkg programs which get invoked during the dpkg run. So any package name
I/O that can have a different meaning depending on which architecture is
native is not acceptable. Affected are also front-ends having an arch
world view calling dpkg multiple times while cross-grading it in one of
those. This dicards considering pkgname equivalent to pkgname:native,
and to print just pkgname when it can be ambiguous (as in possibly
having multiple Multi-Arch: same instances).

This last problematic case is when to arch qualify “M-A: same” instances.
Qualifiying them only when the arch is foreign introduces confusion, as
that depends on which native architecture we are dealing with (c.f.
cross-grading). Qualifying them only when there's more than one instance,
is also problematic as pkgname then changes meaning depending on the
installation or removal order for example.

I also don't think it makes sense to qualify non “M-A: same” foreign
packages, because there's always only going to be one instance, and for
dpkg operations given that there's no ambiguity it does not really matter
which one is there (as long as dependencies are fullfilled, etc). Also
when cross-grading the output could change.

So I changed the code in the pu/multiarch/master to only print the
arch qualifier for all “M-A: same” packages, and not for foreign
non-“M-A: same” ones. This makes the output deterministic and consistent
regardless of the native architecture.

And while it can be argued that this might break backward compatibility,
that's only because Debian will be multiarch enabled, the package name
output will only switch to be arch qualified on distributions that have
had packages marked that way through the field. Others will not get
affected. In addition the fact that almost all shared libraries will
get arch qualified means we'll be able to detect and fix any
script/program not prepared for multiarch pretty quickly, which we have
to do anyway.

One option though if we'd want to preserve output compatibility could be
to only allow co-installability and as such the need to disambiguate
“M-A: same” instances only when a foreign architecture has been configured.

One thing that was brought up previously was --get-selections output,
which is not portable in any way to transport the exact state of packages
installed as that depends on the suite, date, architecture, etc. In
addition not all packages are available on other architectures, and
until now foreign packages have not been exposed explicitly. But we
could extend it to give output to ressemble the current selections.

For package name input, taking into account the output restrictions,
pkgname cannot mean pkgname:native whenever that could be ambiguous
(M-A: same). The only options are then to either consider it pkgname:*
or to fail. I still think pkgname == pkgname:* makes way more sense as
an interface, but failing would also be acceptable to me (as it can
always be switched to pkgname:*).

regards,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111205085510.GA17383@gaara.hadrons.org">http://lists.debian.org/20111205085510.GA17383@gaara.hadrons.org
 
Old 12-12-2011, 08:17 AM
Raphael Hertzog
 
Default Multiarch interfaces: print foreign arches, pkgname I/O

Hi,

On Mon, 05 Dec 2011, Guillem Jover wrote:
> So I changed the code in the pu/multiarch/master to only print the
> arch qualifier for all “M-A: same” packages, and not for foreign
> non-“M-A: same” ones. This makes the output deterministic and consistent
> regardless of the native architecture.

Fine for me. It's not the less disruptive approach but you made a good
case for it.

In general I'm not to worried about dpkg's output changing as long as
scripts can extract values on feed them back to dpkg without unpleasant
surprises.

> One option though if we'd want to preserve output compatibility could be
> to only allow co-installability and as such the need to disambiguate
> “M-A: same” instances only when a foreign architecture has been configured.

I prefer if we stick to the KISS principle so I don't think we want that
extra complexity.

> One thing that was brought up previously was --get-selections output,
> which is not portable in any way to transport the exact state of packages
> installed as that depends on the suite, date, architecture, etc. In
> addition not all packages are available on other architectures, and
> until now foreign packages have not been exposed explicitly. But we
> could extend it to give output to ressemble the current selections.

I would still suggest to keep the default output as portable as possible.

So we would have "libc6 install" by default, and "libc6:<native>" only
if some option was added. Foreign packages would obviously get the
qualifier because we have no better way to express it.

<Thinking out loud>
Maybe if we have multiple M-A: same we would output both "libfoo install"
and "libfoo:<native> install" to ensure we have the same range of
architectures installed when a package is installed for multiple
architectures.
</Thinking out loud>

> For package name input, taking into account the output restrictions,
> pkgname cannot mean pkgname:native whenever that could be ambiguous
> (M-A: same). The only options are then to either consider it pkgname:*
> or to fail. I still think pkgname == pkgname:* makes way more sense as
> an interface, but failing would also be acceptable to me (as it can
> always be switched to pkgname:*).

At least for dpkg --set-selections, I don't agree with this. I would not
like to see the command fail because one M-A: same package listed as
"libfoo install" is already installed.

For the other cases, given the changes in the output of dpkg, I think both
are ok.

Let's go ahead!

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: 20111212091734.GA26970@rivendell.home.ouaza.com">h ttp://lists.debian.org/20111212091734.GA26970@rivendell.home.ouaza.com
 
Old 12-12-2011, 08:55 AM
David Kalnischkies
 
Default Multiarch interfaces: print foreign arches, pkgname I/O

On Mon, Dec 5, 2011 at 09:55, Guillem Jover <guillem@debian.org> wrote:
> One of the issues with cross-grading is that the native architecture for
> the running dpkg can be different than the one for the newly unpacked
> dpkg programs which get invoked during the dpkg run. So any package name
> I/O that can have a different meaning depending on which architecture is
> native is not acceptable. Affected are also front-ends having an arch
> world view calling dpkg multiple times while cross-grading it in one of
> those. This dicards considering pkgname equivalent to pkgname:native,
> and to print just pkgname when it can be ambiguous (as in possibly
> having multiple Multi-Arch: same instances).

Do we really need to worry that much about cross-grades that we need
to change interfaces and even use a different one compared to other tools
working in the same context?
I mean, i don't think it is too much to ask for to understand that if i
change the arch for dpkg that his understanding of native changes, too.

The same is true for APT and all other front-ends, but it seems to be
reasonable to not expect users to fully qualify architectures for all
packages they enter just because libapt might be cross-graded…

In the end, we properly need a specialized tool for cross grades anyway:
Changing the architecture of any package basically requires the
removal of this package before it can be installed for the new architecture:
I e.g. can't think of a good way for APT to instruct dpkg to
remove itself and install itself again in a different architecture…


> So I changed the code in the pu/multiarch/master to only print the
> arch qualifier for all “M-A: same” packages, and not for foreign
> non-“M-A: same” ones. This makes the output deterministic and consistent
> regardless of the native architecture.
>
> And while it can be argued that this might break backward compatibility,
> that's only because Debian will be multiarch enabled, the package name
> output will only switch to be arch qualified on distributions that have
> had packages marked that way through the field. Others will not get
> affected. In addition the fact that almost all shared libraries will
> get arch qualified means we'll be able to detect and fix any
> script/program not prepared for multiarch pretty quickly, which we have
> to do anyway.

You talk only about output, but the title is "I/O" and i think it's unlikely
that dpkg has a different understanding of pkgname in output vs input,
so, you want to tell us that from now on we need to say (native=amd64):
dpkg --configure libc6:amd64 instead of
dpkg --configure libc6 , right?

If that's really meant, i am very worried how release upgrades should
work, given that squeeze tools obviously don't know about this need…


> One option though if we'd want to preserve output compatibility could be
> to only allow co-installability and as such the need to disambiguate
> “M-A: same” instances only when a foreign architecture has been configured.

Not allowing foreign architectures before they are configured would be
preferable, given that front-ends will have a hard time to know which
architectures they can expect -- beside that i wouldn't understand the
difference between:
a) foreign architecture configured and
b) foreign architecture not-configured
given that dpkg would seem to accept a) and b) then without a visible
difference, so why configuring at all…

Also, for compatibility it would be great if for all packages even if it
is not needed an architecture is accepted, e.g. for the foreign M-A: foreign
packages a user might have installed accepting foobar and foobar:armel.


> For package name input, taking into account the output restrictions,
> pkgname cannot mean pkgname:native whenever that could be ambiguous
> (M-A: same). The only options are then to either consider it pkgname:*
> or to fail. I still think pkgname == pkgname:* makes way more sense as
> an interface, but failing would also be acceptable to me (as it can
> always be switched to pkgname:*).

I think Raphael started a discussion on the interface at the beginning of
the year in which it was discussed. I am offline now but i remember to
have typed a long answer and this one is going to be become long already,
so i am not going to repeat it here, just let me reiterate that
a) it feels strange to have different interfaces in the same context
b) requiring different inputs based on the M-A state asks for confusion
c) breaking release upgrades should be avoided


Best regards

David Kalnischkies


P.S.: Thanks Raphael for the forward/reminder on deity. I intended to
send that way earlier, but forgot about it after writing it offline… sorry.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAAZ6_fCWiWdgtzX_E8AxieBavK+D4a2w2syL01ccrKNPWgXxB w@mail.gmail.com">http://lists.debian.org/CAAZ6_fCWiWdgtzX_E8AxieBavK+D4a2w2syL01ccrKNPWgXxB w@mail.gmail.com
 
Old 12-12-2011, 12:37 PM
Raphael Hertzog
 
Default Multiarch interfaces: print foreign arches, pkgname I/O

On Mon, 12 Dec 2011, David Kalnischkies wrote:
> In the end, we properly need a specialized tool for cross grades anyway:
> Changing the architecture of any package basically requires the
> removal of this package before it can be installed for the new architecture:
> I e.g. can't think of a good way for APT to instruct dpkg to
> remove itself and install itself again in a different architecture…

dpkg supports the cross-grade, you can tell it to install a foreign
package when a native one is already installed.

So the goal is to allow the user to cross-grade his system with
a "dpkg -i dpkg_1.16.2_<foreignarch>.deb" (modulo the need to pre-install
the predependencies).

> You talk only about output, but the title is "I/O" and i think it's unlikely
> that dpkg has a different understanding of pkgname in output vs input,
> so, you want to tell us that from now on we need to say (native=amd64):
> dpkg --configure libc6:amd64 instead of
> dpkg --configure libc6 , right?
>
> If that's really meant, i am very worried how release upgrades should
> work, given that squeeze tools obviously don't know about this need…

This proves that we can't make dpkg fail when it gets an unqualified
package name in input. So in the alternatives that guillem proposed
we have to pick "pkgname = pkgname:*" so that things keep working
during upgrade when an old APT drives a new dpkg and that some M-A
libraries are already installed.

> > One option though if we'd want to preserve output compatibility could be
> > to only allow co-installability and as such the need to disambiguate
> > “M-A: same” instances only when a foreign architecture has been configured.
>
> Not allowing foreign architectures before they are configured would be
> preferable, given that front-ends will have a hard time to know which
> architectures they can expect -- beside that i wouldn't understand the
> difference between:
> a) foreign architecture configured and
> b) foreign architecture not-configured
> given that dpkg would seem to accept a) and b) then without a visible
> difference, so why configuring at all…

Foreign architectures packages are already forbidden by default (unless
--force-architecture is in use). I don't know what Guillem was thinking
about, maybe dropping the possibility to override the error.

> I think Raphael started a discussion on the interface at the beginning of
> the year in which it was discussed. I am offline now but i remember to
> have typed a long answer and this one is going to be become long already,
> so i am not going to repeat it here, just let me reiterate that
> a) it feels strange to have different interfaces in the same context
> b) requiring different inputs based on the M-A state asks for confusion
> c) breaking release upgrades should be avoided

My mail: http://lists.debian.org/debian-dpkg/2011/01/msg00046.html
You mail was here:
http://lists.debian.org/debian-dpkg/2011/02/msg00000.html

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: 20111212133736.GC29334@rivendell.home.ouaza.com">h ttp://lists.debian.org/20111212133736.GC29334@rivendell.home.ouaza.com
 
Old 12-12-2011, 01:42 PM
Sven Joachim
 
Default Multiarch interfaces: print foreign arches, pkgname I/O

On 2011-12-12 14:37 +0100, Raphael Hertzog wrote:

> On Mon, 12 Dec 2011, David Kalnischkies wrote:
>> In the end, we properly need a specialized tool for cross grades anyway:
>> Changing the architecture of any package basically requires the
>> removal of this package before it can be installed for the new architecture:
>> I e.g. can't think of a good way for APT to instruct dpkg to
>> remove itself and install itself again in a different architecture…
>
> dpkg supports the cross-grade, you can tell it to install a foreign
> package when a native one is already installed.

How do you do that currently?

> So the goal is to allow the user to cross-grade his system with
> a "dpkg -i dpkg_1.16.2_<foreignarch>.deb" (modulo the need to pre-install
> the predependencies).

With dpkg from your pu/multiarch/full branch, this does not work:

,----
| # dpkg --version
| Debian `dpkg' package management program version 1.16.1.2-171-gae208 (i386).
| This is free software; see the GNU General Public License version 2 or
| later for copying conditions. There is NO warranty.
| # dpkg -i /var/cache/apt/archives/libc-bin_2.13-22_amd64.deb
| dpkg: error processing /var/cache/apt/archives/libc-bin_2.13-22_amd64.deb (--install):
| libc-bin:amd64 2.13-22 (Multi-Arch: foreign) is not co-installable with libc-bin:i386 2.13-22 (Multi-Arch: foreign) which is currently installed
| Errors were encountered while processing:
| /var/cache/apt/archives/libc-bin_2.13-22_amd64.deb
`----

Cheers,
Sven


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87r5094zsv.fsf@turtle.gmx.de">http://lists.debian.org/87r5094zsv.fsf@turtle.gmx.de
 
Old 12-12-2011, 02:17 PM
Raphael Hertzog
 
Default Multiarch interfaces: print foreign arches, pkgname I/O

On Mon, 12 Dec 2011, Sven Joachim wrote:
> > dpkg supports the cross-grade, you can tell it to install a foreign
> > package when a native one is already installed.
> >
> > So the goal is to allow the user to cross-grade his system with
> > a "dpkg -i dpkg_1.16.2_<foreignarch>.deb" (modulo the need to pre-install
> > the predependencies).
>
> With dpkg from your pu/multiarch/full branch, this does not work:
> | # dpkg -i /var/cache/apt/archives/libc-bin_2.13-22_amd64.deb
> | dpkg: error processing /var/cache/apt/archives/libc-bin_2.13-22_amd64.deb (--install):
> | libc-bin:amd64 2.13-22 (Multi-Arch: foreign) is not co-installable with libc-bin:i386 2.13-22 (Multi-Arch: foreign) which is currently installed

Hum, right, it does not work currently. I mixed because I called
cross-grade some tests in the test-suite that ensure that we can switch
between various kind of M-A packages.

So this is currently not supported "as-is" and it would require
supplementary work. It could be fixed though and made to work with a
supplementary --force option.

Sorry for the mis-information.
--
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: 20111212151715.GB30234@rivendell.home.ouaza.com">h ttp://lists.debian.org/20111212151715.GB30234@rivendell.home.ouaza.com
 
Old 12-12-2011, 03:55 PM
Colin Watson
 
Default Multiarch interfaces: print foreign arches, pkgname I/O

On Mon, Dec 12, 2011 at 04:17:15PM +0100, Raphael Hertzog wrote:
> On Mon, 12 Dec 2011, Sven Joachim wrote:
> > With dpkg from your pu/multiarch/full branch, this does not work:
> > | # dpkg -i /var/cache/apt/archives/libc-bin_2.13-22_amd64.deb
> > | dpkg: error processing /var/cache/apt/archives/libc-bin_2.13-22_amd64.deb (--install):
> > | libc-bin:amd64 2.13-22 (Multi-Arch: foreign) is not co-installable with libc-bin:i386 2.13-22 (Multi-Arch: foreign) which is currently installed
>
> Hum, right, it does not work currently. I mixed because I called
> cross-grade some tests in the test-suite that ensure that we can switch
> between various kind of M-A packages.
>
> So this is currently not supported "as-is" and it would require
> supplementary work. It could be fixed though and made to work with a
> supplementary --force option.

Should it even require any forcing? Multi-Arch: foreign basically says
that the package is just as good no matter what architecture it is (as
long as you can execute binaries of that architecture). It seems to me
that if both packages are M-A: foreign then dpkg should just let you
install one over the top of the other as if it were an upgrade.

Such a change would make crossgrades much easier, and doesn't seem to
make anything else worse: for example if apt decides it needs to switch
architectures of an M-A: foreign package (I can't currently think of a
concrete reason why other than crossgrades or explicit requests, but
never mind) it probably has a good reason and it doesn't seem to help
anything for dpkg to require a --force option for it.

(Ian suggested this when I mentioned the problem to him in the pub
recently; I'd been playing with crossgrading a chroot.)

--
Colin Watson [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111212165541.GA573@master.debian.org">http://lists.debian.org/20111212165541.GA573@master.debian.org
 
Old 12-12-2011, 04:14 PM
David Kalnischkies
 
Default Multiarch interfaces: print foreign arches, pkgname I/O

On Mon, Dec 12, 2011 at 16:17, Raphael Hertzog <hertzog@debian.org> wrote:
> On Mon, 12 Dec 2011, Sven Joachim wrote:
>> > dpkg supports the cross-grade, you can tell it to install a foreign
>> > package when a native one is already installed.
>> >
>> > So the goal is to allow the user to cross-grade his system with
>> > a "dpkg -i dpkg_1.16.2_<foreignarch>.deb" (modulo the need to pre-install
>> > the predependencies).
>>
>> With dpkg from your pu/multiarch/full branch, this does not work:
>> | # dpkg -i /var/cache/apt/archives/libc-bin_2.13-22_amd64.deb
>> | dpkg: error processing /var/cache/apt/archives/libc-bin_2.13-22_amd64.deb (--install):
>> | *libc-bin:amd64 2.13-22 (Multi-Arch: foreign) is not co-installable with libc-bin:i386 2.13-22 (Multi-Arch: foreign) which is currently installed
>
> Hum, right, it does not work currently. I mixed because I called
> cross-grade some tests in the test-suite that ensure that we can switch
> between various kind of M-A packages.
>
> So this is currently not supported "as-is" and it would require
> supplementary work. It could be fixed though and made to work with a
> supplementary --force option.

In other word: Never useable by APT or a(ny other) sane front-end.

Beside that i wonder which --force flag this should be, given that it
removes packages while it was requested to install others.
In a way, the old architecture is disappearing, but there are no
Replaces (not even implicit) in place to allow that and the implicit
Conflicts wouldn't allow a seamless disappearing anyway.
So implementing this sounds for me a bit like black voodoo…


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: CAAZ6_fAbiF8auwZf3sC_CGpyvn0+kA5hoKkyB1Ncv1aCqaSG1 g@mail.gmail.com">http://lists.debian.org/CAAZ6_fAbiF8auwZf3sC_CGpyvn0+kA5hoKkyB1Ncv1aCqaSG1 g@mail.gmail.com
 
Old 12-12-2011, 04:15 PM
David Kalnischkies
 
Default Multiarch interfaces: print foreign arches, pkgname I/O

On Mon, Dec 12, 2011 at 14:37, Raphael Hertzog <hertzog@debian.org> wrote:
> On Mon, 12 Dec 2011, David Kalnischkies wrote:
>> You talk only about output, but the title is "I/O" and i think it's unlikely
>> that dpkg has a different understanding of pkgname in output vs input,
>> so, you want to tell us that from now on we need to say (native=amd64):
>> dpkg --configure libc6:amd64 instead of
>> dpkg --configure libc6 , right?
>>
>> If that's really meant, i am very worried how release upgrades should
>> work, given that squeeze tools obviously don't know about this need…
>
> This proves that we can't make dpkg fail when it gets an unqualified
> package name in input. So in the alternatives that guillem proposed
> we have to pick "pkgname = pkgname:*" so that things keep working
> during upgrade when an old APT drives a new dpkg and that some M-A
> libraries are already installed.

So, i am able to (on native=amd64):
dpkg --unpack libc6_i386.deb # unpacking libc6:i386
dpkg --unpack libc6_amd64.deb # unpacking libc6:i386
dpkg --configure libc6 # configuring libc6:amd64 and libc6:i386
dpkg --configure libc6:i386 # does this fail?
dpkg --remove libc6 # removing libc6:i386 and libc6:amd64
?

Users will "love" you for this, given that it is completely inconsistent with
what front-ends will understand if the architecture is omitted…


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: CAAZ6_fCkvKso4Y2zQMxkjbjzfWHSn6Lob17Kk+89PqCnuY=Vo A@mail.gmail.com">http://lists.debian.org/CAAZ6_fCkvKso4Y2zQMxkjbjzfWHSn6Lob17Kk+89PqCnuY=Vo A@mail.gmail.com
 
Old 12-13-2011, 06:15 AM
Raphael Hertzog
 
Default Multiarch interfaces: print foreign arches, pkgname I/O

On Mon, 12 Dec 2011, David Kalnischkies wrote:
> On Mon, Dec 12, 2011 at 14:37, Raphael Hertzog <hertzog@debian.org> wrote:
> > This proves that we can't make dpkg fail when it gets an unqualified
> > package name in input. So in the alternatives that guillem proposed
> > we have to pick "pkgname = pkgname:*" so that things keep working
> > during upgrade when an old APT drives a new dpkg and that some M-A
> > libraries are already installed.
>
> So, i am able to (on native=amd64):
> dpkg --unpack libc6_i386.deb # unpacking libc6:i386
> dpkg --unpack libc6_amd64.deb # unpacking libc6:i386
> dpkg --configure libc6 # configuring libc6:amd64 and libc6:i386
> dpkg --configure libc6:i386 # does this fail?

This last command fails currently, yes.

> dpkg --remove libc6 # removing libc6:i386 and libc6:amd64
> ?

Your description is correct.

> Users will "love" you for this, given that it is completely inconsistent with
> what front-ends will understand if the architecture is omitted…

I am sympathetic to this, but honestly how many people will be affected by
this difference?

I mean the "M-A: same" packages that a user has on its system are pulled
by way of dependencies mainly and are automatically added/removed by APT,
the user is rather unlikely to fiddle with them directly unless he's a
developer with a cross-toolchain and in which case he can certainly learn
this subtlety, no?

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: 20111213071529.GF32642@rivendell.home.ouaza.com">h ttp://lists.debian.org/20111213071529.GF32642@rivendell.home.ouaza.com
 

Thread Tools




All times are GMT. The time now is 09:43 AM.

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