ia32-libs depends on ia32-apt-get ?
Josselin Mouette
as the topic says, I noticed the new ia32-libs package depends on
ia32-apt-get.
This package was already enough of a hack, but at least it worked
without fiddling in horrible ways with the packaging system.
How can we have a working wine or nspluginwrapper now?
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
Norbert Preining
> This package was already enough of a hack, but at least it worked
> without fiddling in horrible ways with the packaging system.
>
> How can we have a working wine or nspluginwrapper now?
Not that I know about nspluginwrapper, but I got my skype working again
by:
- calling /usr/share/ia32-apt-get/convert-all-sources.list
- increaing Cache-Limit in /etc/apt/conf.d/00cachesize
- calling apt-get update from the commandline
- installing skype from aptitude
> `. `' “I recommend you to learn English in hope that you in
> `- future understand things” -- Jörg Schilling
Great, thanks. My most beloved JS.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <prei...@logic.at> Vienna University of Technology
Debian Developer <prei...@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
And finally, " said Max, quieting the audience down and
putting on his solemn face, "finally I believe we have with
us here tonight, a party of believers, very devout
believers, from the Church of the Second Coming of the
Great Prophet Zarquon. " ... "There they are, " said Max,
"sitting there, patiently. He said he'd come again, and
he's kept you waiting a long time, so let's hope he's
hurrying fellas, because he's only got eight minutes left!
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Didier 'OdyX' Raboud
Norbert Preining wrote:
> On Mo, 29 Jun 2009, Josselin Mouette wrote:
>> This package was already enough of a hack, but at least it worked
>> without fiddling in horrible ways with the packaging system.
>>
>> How can we have a working wine or nspluginwrapper now?
>
> Not that I know about nspluginwrapper, but I got my skype working again
> by:
> - calling /usr/share/ia32-apt-get/convert-all-sources.list
Which horribly breaks with anything a little custom (proxies, custom
repositories, ...) and fills your /etc/apt/sources.list.d/ with ia32-apt-
get.{i386,amd64} copies of all your pet sources.
It also breaks on install if there is no /etc/apt/sources.list (which is
obviously unuseful if you have filled your /etc/apt/sources.list.d/ ).
> - increaing Cache-Limit in /etc/apt/conf.d/00cachesize
I did that configuration in /etc/apt/apt.conf.d/99custom by the way (for
other things)...
> - calling apt-get update from the commandline
It dpkg-diverts apt-get but not aptitude... How can we accept to see apt-get
diverted for such a hack ?
> - installing skype from aptitude
Personnally, I don't care for non-free stuff, but main's wine depends on
ia32-apt-get through ia32-libs…
Regards,
OdyX, who points to multiarch and suggests it is maybe time to go the real
route instead…
--
Didier Raboud, proud Debian user.
CH-1802 Corseaux
did...@raboud.com
Norbert Preining
> OdyX, who points to multiarch and suggests it is maybe time to go the real
> route instead…
Not that i am happy with the current status, but at least I managed to
get some things working again.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <prei...@logic.at> Vienna University of Technology
Debian Developer <prei...@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
TWEEDSMUIR (collective n.)
The name given to the extensive collection of hats kept in the
downstairs lavatory which don't fit anyone in the family.
--- Douglas Adams, The Meaning of Liff
Goswin von Brederlow
> Hi,
>
> Norbert Preining wrote:
>> On Mo, 29 Jun 2009, Josselin Mouette wrote:
>>> This package was already enough of a hack, but at least it worked
>>> without fiddling in horrible ways with the packaging system.
>>>
>>> How can we have a working wine or nspluginwrapper now?
>>
>> Not that I know about nspluginwrapper, but I got my skype working again
>> by:
>> - calling /usr/share/ia32-apt-get/convert-all-sources.list
>
> Which horribly breaks with anything a little custom (proxies, custom
> repositories, ...) and fills your /etc/apt/sources.list.d/ with ia32-apt-
> get.{i386,amd64} copies of all your pet sources.
Examples please.
> It also breaks on install if there is no /etc/apt/sources.list (which is
> obviously unuseful if you have filled your /etc/apt/sources.list.d/ ).
>
>> - increaing Cache-Limit in /etc/apt/conf.d/00cachesize
>
> I did that configuration in /etc/apt/apt.conf.d/99custom by the way (for
> other things)...
>
>> - calling apt-get update from the commandline
>
> It dpkg-diverts apt-get but not aptitude... How can we accept to see apt-get
> diverted for such a hack ?
You don't have too but then you won't get 32bit support beyond the
verry core libs needed for gcc-multilib.
The reasons for ia32-apt-get are this:
- multiarch is still not there.
- ia32-libs source with all the additional request libs grows to about
1GB in size of which everything is pure duplication.
- ia32-libs contains so many libs that it needs a new upload every
other day (or is constantly out of sync like it always was).
- ia32-libs can only cover unstable or testing but not both.
- ia32-libs has no security support but security bugs.
- ia32-libs doesn't ensure library versions are new (or old) enough
to work with 3rd party debs. They easily miss a library or get a
wrong version.
- ftp-master has vetoed splitting ia32-libs into individual packages
and shown a strong dislike to ia32-libs as it was.
- ia32-libs doesn't allow to install 3rd party 32bit debs or use 3rd
party apt repositories with 32bit packages.
>> - installing skype from aptitude
>
> Personnally, I don't care for non-free stuff, but main's wine depends on
> ia32-apt-get through ia32-libs…
apt-get install ia32-wine (tested with the experimental wine)
> Regards,
>
> OdyX, who points to multiarch and suggests it is maybe time to go the real
> route instead…
MfG
Goswin
Josselin Mouette
> The reasons for ia32-apt-get are this:
There are good reasons for ia32-apt-get to exist. But the implementation
is so horribly wrong that it gives me headaches only thinking about it.
It is nothing but a giant hack on which it is not reasonable to rely for
important packages like wine.
--
.''`. Josselin Mouette
: :' :
Didier 'OdyX' Raboud
> Didier 'OdyX' Raboud <did...@raboud.com> writes:
>> Norbert Preining wrote:
>>> - calling /usr/share/ia32-apt-get/convert-all-sources.list
>>
>> Which horribly breaks with anything a little custom (proxies, custom
>> repositories, ...) and fills your /etc/apt/sources.list.d/ with ia32-apt-
>> get.{i386,amd64} copies of all your pet sources.
>
> Examples please.
Hi Goswin,
Here is an example from my laptop :
I don't have an /etc/apt/sources.list , so installation fails (#534979). In
my /etc/apt/sources.list.d, I have 4 files :
* 00_particulars.list, which contains various repositories, some of them
commented, some of them not, mostly unused now.
* 10_apt-proxy.list, which contains lines for my home apt-proxy-ng with
testing, t-p-u, unstable, experimental and testing/updates.
* 20_std.list.dis and 30_local_pbuilder.list.dis, both disabled for aptitude
(fallback and intent).
You'll find them in the attached apt_sources_list_d.tar.bz2.
# touch /etc/apt/sources.list; aptitude install ia32-apt-get
(Does it really generate a gpg key as root, asking me to move the mouse ?)
Then, in /etc/apt/sources.list.d/, in addition to _MY_ 4 files, I have the
following list :
ia32-apt-get.amd64.00_particulars.list
(Completely broken, no valid repository)
ia32-apt-get.amd64.list
(empty)
ia32-apt-get.i386.ia32-apt-get-transitional.list
(transitional-i386/main not found => nothing valid)
ia32-apt-get.amd64.10_apt-proxy.list
(Completely broken, no valid repository)
ia32-apt-get.i386.00_particulars.list
(Completely broken, no valid repository)
ia32-apt-get.i386.list
(empty)
ia32-apt-get.amd64.ia32-apt-get-transitional.list
(transitional-amd64/main not found => nothing valid)
ia32-apt-get.i386.10_apt-proxy.list
(Completely broken, no valid repository)
ia32-apt-get-transitional.list
(WORKS ! - Contains ia32-libs{,-gtk} 1:3.0)
So among the 9 packages prepared by ia32-apt-get postinst, one is working.
All others are broken.
You'll find them in the attached apt_sources_list_d_after.tar.bz2.
Is that enough of an example ?
>>> - calling apt-get update from the commandline
>>
>> It dpkg-diverts apt-get but not aptitude... How can we accept to see
>> apt-get diverted for such a hack ?
>
> You don't have too but then you won't get 32bit support beyond the
> verry core libs needed for gcc-multilib.
Sorry, but if I install wine, I don't have the choice to have apt-get _not_
diverted…
> The reasons for ia32-apt-get are this:
>
> - multiarch is still not there.
> - ia32-libs source with all the additional request libs grows to about
> 1GB in size of which everything is pure duplication.
> - ia32-libs contains so many libs that it needs a new upload every
> other day (or is constantly out of sync like it always was).
> - ia32-libs can only cover unstable or testing but not both.
> - ia32-libs has no security support but security bugs.
> - ia32-libs doesn't ensure library versions are new (or old) enough
> to work with 3rd party debs. They easily miss a library or get a
> wrong version.
> - ftp-master has vetoed splitting ia32-libs into individual packages
> and shown a strong dislike to ia32-libs as it was.
> - ia32-libs doesn't allow to install 3rd party 32bit debs or use 3rd
> party apt repositories with 32bit packages.
I very much understand all those reasons. I still think that the actual
response ia32-apt-get provides is actually not good enough to let things
like wine rely on.
I would largely prefer if ia32-* in its actual shape would be released in
experimental (where, with this level of touching the base of Debian
repositories handling, it should sit) and version 2.7 uploaded back in
Sid...
Regards,
Goswin von Brederlow
I get:
deb ftp://ftp.uni-kl.de/debian-multimedia/ testing-amd64 main
deb ftp://ftp.uni-kl.de/debian-multimedia/ unstable-amd64 main
deb ftp://ftp.uni-kl.de/debian-multimedia/ experimental-amd64 main
deb http://kernel-archive.buildserver.net/debian-kernel sid-amd64 main
deb http://kernel-archive.buildserver.net/debian-kernel trunk-amd64 main
deb http://pkg-fso.alioth.debian.org/debian unstable-amd64 main
and all the comments. That looks just fine.
> ia32-apt-get.amd64.list
> (empty)
Expected as sources.list is empty.
> ia32-apt-get.i386.ia32-apt-get-transitional.list
> (transitional-i386/main not found => nothing valid)
> ia32-apt-get.amd64.10_apt-proxy.list
> (Completely broken, no valid repository)
deb http://apt.#HIDDEN#:3142/debian/ testing-amd64 main contrib non-free
deb http://apt.#HIDDEN#:3142/debian/ testing-proposed-updates-amd64 main contrib non-free
...
looks fine too.
> ia32-apt-get.i386.00_particulars.list
> (Completely broken, no valid repository)
> ia32-apt-get.i386.list
> (empty)
> ia32-apt-get.amd64.ia32-apt-get-transitional.list
> (transitional-amd64/main not found => nothing valid)
> ia32-apt-get.i386.10_apt-proxy.list
> (Completely broken, no valid repository)
Same as the respecive file of the other arch.
> ia32-apt-get-transitional.list
> (WORKS ! - Contains ia32-libs{,-gtk} 1:3.0)
>
> So among the 9 packages prepared by ia32-apt-get postinst, one is working.
> All others are broken.
>
> You'll find them in the attached apt_sources_list_d_after.tar.bz2.
>
> Is that enough of an example ?
Not realy. None of your entries causes an error. They all convert
perfectly.
What do you mean "no valid repository"? Are you trying to use them
without first having called "apt-get update" to actualy create the
index files they reference? So far everything you have shown is as
designed.
Conflicts with libc6-i386.
> Regards,
Didier Raboud
> Didier 'OdyX' Raboud <did...@raboud.com> writes:
>> Goswin von Brederlow wrote:
>>> Didier 'OdyX' Raboud <did...@raboud.com> writes:
>>>> Norbert Preining wrote:
>>>>> - calling /usr/share/ia32-apt-get/convert-all-sources.list
>>>>
>>>> Which horribly breaks with anything a little custom (proxies, custom
>>>> repositories, ...) and fills your /etc/apt/sources.list.d/ with
>>>> ia32-apt- get.{i386,amd64} copies of all your pet sources.
>>>
>>> Examples please.
>>
>> Hi Goswin,
>>
>> Here is an example from my laptop :
>>
>>
>> Is that enough of an example ?
>
> Not realy. None of your entries causes an error. They all convert
> perfectly.
>
> What do you mean "no valid repository"? Are you trying to use them
> without first having called "apt-get update" to actualy create the
> index files they reference? So far everything you have shown is as
> designed.
Okay. This is #533746 then. I do always use aptitude (both command-line only
and with the curses interface) and never apt-get. You cannot expect me to
use apt-get AFAIK.
While installing wine (e.g) with aptitude, I cannot except to get new
archives added to my sources.list which should be somehow mangled by a
wrapper around apt-get, which I should begin to use instead of aptitude.
s/apt-get/aptitude/g is really too much of an intrusion in the way I admin
my machines... Sorry.
> MfG
> Goswin
I feel good intentions, but a poor result. This really seems a big plaster
on a wooden leg.
Regards,
OdyX
Goswin von Brederlow
It is work in progress. For now you will have to "apt-get update" and
then you can use aptitude for everything else.
I never use aptitude and after doing a test upgrade of an older sid to
current with aptitude I'm verry much affirmed on that. The last ~50
packages I upgraded with "apt-get upgrade" again because the aptitude
interface just wouldn't just do it.
Aptitude even suggested I downgrade some package from 1.2-3 (64bit
flavour) to 1.2-3~18 (32bit flavour) despite the later being pinned
down. That is just horribly broken. apt-get just updated the package
and its dependency instead.
>> MfG
>> Goswin
>
> I feel good intentions, but a poor result. This really seems a big plaster
> on a wooden leg.
>
> Regards,
>
> OdyX
MfG
Goswin
Josselin Mouette
> I never use aptitude and after doing a test upgrade of an older sid to
> current with aptitude I'm verry much affirmed on that. The last ~50
> packages I upgraded with "apt-get upgrade" again because the aptitude
> interface just wouldn't just do it.
>
> Aptitude even suggested I downgrade some package from 1.2-3 (64bit
> flavour) to 1.2-3~18 (32bit flavour) despite the later being pinned
> down. That is just horribly broken. apt-get just updated the package
> and its dependency instead.
Aptitude’s (well-known) brokenness is irrelevant. There are many other
APT frontents, like synaptic, which don’t have broken dependency
management, and which will fail just as well with ia32-apt-get.
I wonder how you could even think once that diverting apt-get was a good
idea. If you need to hook into APT to convert packages and package lists
on-the-fly, work with the APT maintainers so that APT provides hooks
usable for that effect. But DO NOT BREAK the existing APT configuration.
--
.''`. Josselin Mouette
: :' :
Lionel Elie Mamane
happened, but after the upgrade of ia32-apt-get 14 to 18, suddenly
aptitude had about 200 package in "upgradable" state that were not
upgradable before.
The issue is I don't remember for sure what /etc/apt/sources.list
looked like before the upgrade, but now it is:
lionelm@harif:/etc/apt$ cat preferences
Package: *
Pin: release a=testing
Pin-Priority: 600
lionelm@harif:/etc/apt$ cat sources.list
deb http://ftp.surfnet.nl/os/Linux/distr/debian/ lenny main
deb http://ftp.surfnet.nl/os/Linux/distr/debian/ sid main
deb-src http://ftp.surfnet.nl/os/Linux/distr/debian/ lenny main
deb http://security.eu.debian.org/ lenny/updates main
deb-src http://security.eu.debian.org/ lenny/updates main
lionelm@harif:/etc/apt$ for f in sources.list.d/*; do echo $f; echo --------; cat $f; done
sources.list.d/ia32-apt-get.amd64.ia32-apt-get-transitional.list
--------
# This adds the ia32-libs and ia32-libs-gtk transitional packages
deb file:///usr/share/ia32-apt-get transitional-amd64 main
sources.list.d/ia32-apt-get.amd64.list
--------
deb http://ftp.surfnet.nl/os/Linux/distr/debian/ lenny-amd64 main
deb http://ftp.surfnet.nl/os/Linux/distr/debian/ sid-amd64 main
deb http://security.eu.debian.org/ lenny/updates-amd64 main
sources.list.d/ia32-apt-get.i386.ia32-apt-get-transitional.list
--------
# This adds the ia32-libs and ia32-libs-gtk transitional packages
deb file:///usr/share/ia32-apt-get transitional-i386 main
sources.list.d/ia32-apt-get.i386.list
--------
deb http://ftp.surfnet.nl/os/Linux/distr/debian/ lenny-i386 main
deb http://ftp.surfnet.nl/os/Linux/distr/debian/ sid-i386 main
deb http://security.eu.debian.org/ lenny/updates-i386 main
sources.list.d/ia32-apt-get-transitional.list
--------
# This adds the ia32-libs and ia32-libs-gtk transitional packages
deb file:///usr/share/ia32-apt-get transitional main
--
Lionel
Hans-J. Ullrich
> Aptitude’s (well-known) brokenness is irrelevant. There are many other
> APT frontents, like synaptic, which don’t have broken dependency
> management, and which will fail just as well with ia32-apt-get.
>
> I wonder how you could even think once that diverting apt-get was a good
> idea. If you need to hook into APT to convert packages and package lists
> on-the-fly, work with the APT maintainers so that APT provides hooks
> usable for that effect. But DO NOT BREAK the existing APT configuration.
Please, I do not want to start flamewars, but somebody told me, that aptitude
is the recommended tool to install packages, and apt-get is orphaned.
Hmm, o.k., apt-get is working for me, this is o.k., but I ask myself now: What
is the recommended tool in future? Especially, as the handling of dependencies
and packages in apt-get, aptitude and synaptic are in each different ways.
Again: This shall be no flamewar!!!
Thanks
Hans
Goswin von Brederlow
> While we are on the subject of ia32-apt-get, I'm not sure _what_
> happened, but after the upgrade of ia32-apt-get 14 to 18, suddenly
> aptitude had about 200 package in "upgradable" state that were not
> upgradable before.
ia32-apt-get encodes its own version into the version of converted
packages. That way every time the converter fixes some bug all
converted packages get upgraded to a new version. That might not be
always neccessary but generally is.
So this is totaly expected.
> The issue is I don't remember for sure what /etc/apt/sources.list
> looked like before the upgrade, but now it is:
>
> lionelm@harif:/etc/apt$ cat preferences
> Package: *
> Pin: release a=testing
> Pin-Priority: 600
Better add the pinings from /usr/share/doc/ia32-apt-get/NEWS.Debian.gz
as well.
MfG
Goswin
Josselin Mouette
> Hmm, o.k., apt-get is working for me, this is o.k., but I ask myself now: What
> is the recommended tool in future? Especially, as the handling of dependencies
> and packages in apt-get, aptitude and synaptic are in each different ways.
All existing frontends use the same dependency resolution engine, except
for aptitude. Installing a package with synaptic, apt-get, adept or
gnome-app-install should give the same result.
Cheers,
Cyril Brulebois
> All existing frontends use the same dependency resolution engine,
> except for aptitude. Installing a package with synaptic, apt-get,
> adept or gnome-app-install should give the same result.
cupt! cupt! cupt!
Mraw,
KiBi.
Lionel Elie Mamane
> Lionel Elie Mamane <lio...@mamane.lu> writes:
>> While we are on the subject of ia32-apt-get, I'm not sure _what_
>> happened, but after the upgrade of ia32-apt-get 14 to 18, suddenly
>> aptitude had about 200 package in "upgradable" state that were not
>> upgradable before.
> ia32-apt-get encodes its own version into the version of converted
> packages. That way every time the converter fixes some bug all
> converted packages get upgraded to a new version. That might not be
> always neccessary but generally is.
> So this is totaly expected.
Well, I most certainly didn't have 200 i386 packages installed, I must
have had maybe 10 of them, so this cannot be the complete
explanation. When I do a "spot check" on a few specific packages, it
seems I went from testing to unstable. For example, take cheese:
[UPGRADE] cheese 2.24.3-2 -> 2.26.2-1
It went from the squeeze version to the sid version. So the behaviour
is as if squeeze had been dropped from my sources.list. Ah, but I have
daily backups of that machine! Let's see. Yes! That's it. The upgrade
removed squeeze from my sources.list. Here is my sources.list before
the upgrade:
deb http://ftp.nl.debian.org/debian/ squeeze main contrib non-free
deb http://ftp.nl.debian.org/debian/ sid main contrib non-free
deb-src http://ftp.nl.debian.org/debian/ sid main contrib non-free
deb http://security.eu.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.eu.debian.org/ squeeze/updates main contrib non-free
### ia32-apt-get entries ###
#deb http://ftp.surfnet.nl/os/Linux/distr/debian/ lenny-i386 main
#deb http://ftp.surfnet.nl/os/Linux/distr/debian/ sid-i386 main
#deb http://security.eu.debian.org/ lenny/updates-i386 main
After, no trace of squeeze anymore. Filing a bug.
>> The issue is I don't remember for sure what /etc/apt/sources.list
>> looked like before the upgrade, but now it is:
>> lionelm@harif:/etc/apt$ cat preferences
>> Package: *
>> Pin: release a=testing
>> Pin-Priority: 600
> Better add the pinings from /usr/share/doc/ia32-apt-get/NEWS.Debian.gz
> as well.
The example in there seems to be missing "transitional-i386" and maybe
also "transitional"?
--
Lionel
Mehdi Dogguy
> Hi,
>
> as the topic says, I noticed the new ia32-libs package depends on
> ia32-apt-get.
>
I searched the list archive and found only one thread[1] related to
ia32-apt-get. Correct me if I'm wrong but it was clear for me, when
reading comments, that the solution was not acceptable and no consensus
was reached.
So why was it uploaded without further discussions on the list?
Shouldn't be uploaded into experimental instead of unstable? … Do you
consider it as a “releasable” solution?
How would aptitude users do now?
[1] http://lists.debian.org/debian-devel/2009/03/msg01849.html
Cheers,
--
Mehdi Dogguy مهدي الدڤي
http://www.pps.jussieu.fr/~dogguy
Tel.: (+33).1.44.27.28.38
Goswin von Brederlow
> Josselin Mouette wrote:
>> Hi,
>>
>> as the topic says, I noticed the new ia32-libs package depends on
>> ia32-apt-get.
>>
>
> I searched the list archive and found only one thread[1] related to
> ia32-apt-get. Correct me if I'm wrong but it was clear for me, when
> reading comments, that the solution was not acceptable and no consensus
> was reached.
>
> So why was it uploaded without further discussions on the list?
Because there where no ideas brought forward to discuss.
There where 3 options:
1) ia32-libs + ia32-libs-gtk (+ ia32-libs-kde + ia32-libs-qt)
ftp-master asked us to clean that up basically and
"it would not pass NEW if it where uploaded now"
2) ia32-lib* packages in the same schema as ia32-libs
vetoed by ftp-master for being way to many packages as ugly as
ia32-libs
3) ia32-apt-get
So strike option 1 and 2 and what are you left with?
> Shouldn't be uploaded into experimental instead of unstable? … Do you
The libc6-i386 lib32 transition was easier done by switching to
ia32-apt-get now than to rewrite ia32-libs for it. So that kind of
forced the issue.
> consider it as a “releasable” solution?
Going to be.
> How would aptitude users do now?
apt-get update; aptitude
> [1] http://lists.debian.org/debian-devel/2009/03/msg01849.html
>
> Cheers,
MfG
Goswin
Josselin Mouette
> > consider it as a “releasable†solution?
>
> Going to be.
No, it is not going to be. The whole design needs work before it can be.
> > How would aptitude users do now?
>
> apt-get update; aptitude
And how would synaptic users do?
Goswin von Brederlow
Since that was with ia32-apt-get prior to version 15 the relevant
sources.list file would have been /etc/apt/native/sources.list.
I suspect you added squeeze to /etc/apt/sources.list after installing
ia32-apt-get the first time and possibly removing (but not purging) it.
I should probably add a debconf question there asking what to do
instead of restoring the sources.list from before ia32-apt-get.
>>> The issue is I don't remember for sure what /etc/apt/sources.list
>>> looked like before the upgrade, but now it is:
>
>>> lionelm@harif:/etc/apt$ cat preferences
>>> Package: *
>>> Pin: release a=testing
>>> Pin-Priority: 600
>
>> Better add the pinings from /usr/share/doc/ia32-apt-get/NEWS.Debian.gz
>> as well.
>
> The example in there seems to be missing "transitional-i386" and maybe
> also "transitional"?
Only 2 arch:all meta packages there and the -amd64 or transitional one
will always be a higher version. I will probably filter the
transitional-$(arch) entries out in the future as they are completly
useless and confusing (but not harmfull in any way).
> --
> Lionel
MfG
Goswin
Mark Brown
> On Mon, Jun 29, 2009 at 17:30:35 +0200, Goswin von Brederlow wrote:
> > So strike option 1 and 2 and what are you left with?
> Figure out an acceptable option 4.
Multiarch was mentioned in the original thread.
Julien Cristau
> There where 3 options:
>
> 1) ia32-libs + ia32-libs-gtk (+ ia32-libs-kde + ia32-libs-qt)
> ftp-master asked us to clean that up basically and
> "it would not pass NEW if it where uploaded now"
>
> 2) ia32-lib* packages in the same schema as ia32-libs
> vetoed by ftp-master for being way to many packages as ugly as
> ia32-libs
>
> 3) ia32-apt-get
>
> So strike option 1 and 2 and what are you left with?
>
Figure out an acceptable option 4.
Cheers,
Julien
Norbert Preining
> > Figure out an acceptable option 4.
>
> Multiarch was mentioned in the original thread.
Not that I was happy with the original situation (filing myself a bug),
but all that "multiarch" blabla and nothing is going forward in this
direction, so this is not a reasonable solution until nobody steps
forward and does the work for that.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <prei...@logic.at> Vienna University of Technology
Debian Developer <prei...@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
QUEENZIEBURN (n.)
Something that happens when people make it up after an agglethorpe
(q.v.)
--- Douglas Adams, The Meaning of Liff
Mark Brown
> On Mo, 29 Jun 2009, Mark Brown wrote:
> > Multiarch was mentioned in the original thread.
> Not that I was happy with the original situation (filing myself a bug),
> but all that "multiarch" blabla and nothing is going forward in this
> direction, so this is not a reasonable solution until nobody steps
> forward and does the work for that.
There seems to be at least some crossover between the people who were
looking at multiarch and the people doing this stuff.
Raphael Hertzog
> On Mo, 29 Jun 2009, Mark Brown wrote:
> > > Figure out an acceptable option 4.
> >
> > Multiarch was mentioned in the original thread.
>
> Not that I was happy with the original situation (filing myself a bug),
> but all that "multiarch" blabla and nothing is going forward in this
> direction, so this is not a reasonable solution until nobody steps
> forward and does the work for that.
There is work going on recently. Steve Langasek drafted a plan that he
wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by
Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a
reality inside Debian but I don't know of any timeframe.
https://wiki.ubuntu.com/MultiarchSpec
Cheers,
--
Raphaï¿œl Hertzog
Contribuez ￜ Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/
Matthew Johnson
> On Mon, 29 Jun 2009, Norbert Preining wrote:
> > On Mo, 29 Jun 2009, Mark Brown wrote:
> > > > Figure out an acceptable option 4.
> > >
> > > Multiarch was mentioned in the original thread.
> >
> > Not that I was happy with the original situation (filing myself a bug),
> > but all that "multiarch" blabla and nothing is going forward in this
> > direction, so this is not a reasonable solution until nobody steps
> > forward and does the work for that.
>
> There is work going on recently. Steve Langasek drafted a plan that he
> wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by
> Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a
> reality inside Debian but I don't know of any timeframe.
>
> https://wiki.ubuntu.com/MultiarchSpec
I have offered to help with this, if someone can tell me what needs to
be done.
This is something I'd hoped would be pushed out through Debian to other
distributions, not yet another thing which Ubuntu innovates and then we
merge back in later.
Matt
--
Matthew Johnson
Goswin von Brederlow
> Le lundi 29 juin 2009 à 17:30 +0200, Goswin von Brederlow a écrit :
>> > consider it as a “releasable†solution?
>>
>> Going to be.
>
> No, it is not going to be. The whole design needs work before it can be.
There is a better design. It is called multiarch. But some people are
blocking that.
>> > How would aptitude users do now?
>>
>> apt-get update; aptitude
>
> And how would synaptic users do?
apt-get update; synaptic
Do you see a pattern?
In synaptic Edit->"Reload package information" needs to be adapted and
Settings->Repositories.
Goswin von Brederlow
> On Mon, Jun 29, 2009 at 06:12:20PM +0200, Norbert Preining wrote:
>> On Mo, 29 Jun 2009, Mark Brown wrote:
>
>> > Multiarch was mentioned in the original thread.
>
>> Not that I was happy with the original situation (filing myself a bug),
>> but all that "multiarch" blabla and nothing is going forward in this
>> direction, so this is not a reasonable solution until nobody steps
>> forward and does the work for that.
>
> There seems to be at least some crossover between the people who were
> looking at multiarch and the people doing this stuff.
But not the people blocking the inclusion of patches for multiarch
already present in the BTS.
MfG
Goswin
Josselin Mouette
> Josselin Mouette <jo...@debian.org> writes:
> > No, it is not going to be. The whole design needs work before it can be.
>
> There is a better design. It is called multiarch. But some people are
> blocking that.
Identify the blockers. Work with people interested in this, so that
appropriate action is taken. If people are working against it, we can
invoke the TC. All of this, if you do things by the rules.
If you continue to push broken software, we will have no other solution
but to remove them from the archive.
> >> > How would aptitude users do now?
> >>
> >> apt-get update; aptitude
> >
> > And how would synaptic users do?
>
> apt-get update; synaptic
>
> Do you see a pattern?
Yes, I see that you don’t understand that ia32-apt-get is FUBAR.
> In synaptic Edit->"Reload package information" needs to be adapted and
> Settings->Repositories.
No. Adapting each and every APT frontend is not the way to go.
Goswin von Brederlow
> On Mon, 29 Jun 2009, Norbert Preining wrote:
>> On Mo, 29 Jun 2009, Mark Brown wrote:
>> > > Figure out an acceptable option 4.
>> >
>> > Multiarch was mentioned in the original thread.
>>
>> Not that I was happy with the original situation (filing myself a bug),
>> but all that "multiarch" blabla and nothing is going forward in this
>> direction, so this is not a reasonable solution until nobody steps
>> forward and does the work for that.
>
> There is work going on recently. Steve Langasek drafted a plan that he
> wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by
> Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a
> reality inside Debian but I don't know of any timeframe.
>
> https://wiki.ubuntu.com/MultiarchSpec
>
> Cheers,
Too bad they did that without involving the people already working on
multiarch via the alioth project.
They messed up some finer details, broke the existing patches, made
the whole thing need a full release cycle for a transition due to
DEBIAN/control format changes and have a broen plan for -dev packages.
Guillem Jover is also blocking the inclusion of already existing
patches for multiarch.
Frustrated,
Goswin
Matthew Johnson
> > There is work going on recently. Steve Langasek drafted a plan that he
> > wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by
> > Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a
> > reality inside Debian but I don't know of any timeframe.
> >
> > https://wiki.ubuntu.com/MultiarchSpec
> >
> > Cheers,
>
> Too bad they did that without involving the people already working on
> multiarch via the alioth project.
>
> They messed up some finer details, broke the existing patches, made
> the whole thing need a full release cycle for a transition due to
> DEBIAN/control format changes and have a broen plan for -dev packages.
Ok, For those of us who haven't been following all of the bug reports
and threads covering this, perhaps we could have a summary here of what
you think needs doing to get multiarch working, what needs changing and
what objections people have to changing it.
I would love to see this in (or the required changes so that it can be
in squeeze+1) in squeeze and now is the time to do it.
I've also CC'd Hector and Steve who are listed as owners on that
document because whatever we do to get multiarch working (and I have no
strong views on the right way to do it) we should definitely not do it
differently to Ubuntu.
Yannick
> There where 3 options:
>
> 1) ia32-libs + ia32-libs-gtk (+ ia32-libs-kde + ia32-libs-qt)
> ftp-master asked us to clean that up basically and
> "it would not pass NEW if it where uploaded now"
>
> 2) ia32-lib* packages in the same schema as ia32-libs
> vetoed by ftp-master for being way to many packages as ugly as
> ia32-libs
>
> 3) ia32-apt-get
>
> So strike option 1 and 2 and what are you left with?
Isn't it possible to have a system similar to apt-build?
One would do "ia32-apt-convert ia32-libfoo" that would convert libfoo 32bits
package and its dependencies, put it in a local repository. Then the user
could install ia32-libfoo with apt-get, aptitude, whatever.
Yannick
PS: Of course, there would be a ia32-apt-update to update all the ia32-*
installed.
Yannick
> Better add the pinings from /usr/share/doc/ia32-apt-get/NEWS.Debian.gz
> as well.
Goswin, you should put a "debconf warning" to point the apt pining solution
to the user.
Yannick
Steve Langasek
> Mehdi Dogguy <mehdi....@pps.jussieu.fr> writes:
> Because there where no ideas brought forward to discuss.
> There where 3 options:
> 1) ia32-libs + ia32-libs-gtk (+ ia32-libs-kde + ia32-libs-qt)
> ftp-master asked us to clean that up basically and
> "it would not pass NEW if it where uploaded now"
> 2) ia32-lib* packages in the same schema as ia32-libs
> vetoed by ftp-master for being way to many packages as ugly as
> ia32-libs
> 3) ia32-apt-get
- Proper multiarch support in dpkg and apt, which is now being worked on,
and from which this thread is a distraction.
--
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/
slan...@ubuntu.com vor...@debian.org
Raphael Hertzog
> Too bad they did that without involving the people already working on
> multiarch via the alioth project.
>
> They messed up some finer details, broke the existing patches, made
> the whole thing need a full release cycle for a transition due to
> DEBIAN/control format changes and have a broen plan for -dev packages.
>
> Guillem Jover is also blocking the inclusion of already existing
> patches for multiarch.
I'm sorry but I have much more confidence in Guillem's and Steve's
technical abilities than in yours.
I can understand your frustration but you never offered a viable and clean
long-term solution. Sending patches to dpkg to add/enable a Multi-Arch field
without making use of it and/or explaining the whole plan and rationale
is far from good.
I would also not merge patches without knowing if the full plan is
credible.
Cheers,
--
Raphaï¿œl Hertzog
Contribuez ￜ Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/
Josselin Mouette
> I would also not merge patches without knowing if the full plan is
> credible.
This is the precise point that seems to be missing.
Goswin, if you have a prototype multiarch system based on unstable that
mostly works, with patches for all pieces that need changes, that would
help a lot in convincing people.
Goswin von Brederlow
> Le lundi 29 juin 2009 à 21:30 +0200, Goswin von Brederlow a écrit :
>> Josselin Mouette <jo...@debian.org> writes:
>> > No, it is not going to be. The whole design needs work before it can be.
>>
>> There is a better design. It is called multiarch. But some people are
>> blocking that.
>
> Identify the blockers. Work with people interested in this, so that
Currently the blocker is Guillem Jover <gui...@debian.org> as you can
see in Bugs #528205, #528140, #528143, #528194, #528198, #528141. I
stopped filing more after that.
As said in the bugs I've taken the discussion to debian-dpkg:
http://lists.debian.org/debian-dpkg/2009/05/msg00031.html
As you can see it just hits the wall of silence. Same thing that
happened to the binutils, gcc and dpkg patches for years now.
This really makes me wonder. Don't they want to have multiarch support
in Debian? Do they want Ubuntu to have it first and be the saviour of
Debian?
> appropriate action is taken. If people are working against it, we can
> invoke the TC. All of this, if you do things by the rules.
>
> If you continue to push broken software, we will have no other solution
> but to remove them from the archive.
>
>> >> > How would aptitude users do now?
>> >>
>> >> apt-get update; aptitude
>> >
>> > And how would synaptic users do?
>>
>> apt-get update; synaptic
>>
>> Do you see a pattern?
>
> Yes, I see that you don’t understand that ia32-apt-get is FUBAR.
ia32-libs and ia32-atpt-get is a dirty ugly horrible hack. That is why
over 5 years ago some people got together and worked out the multiarch
proposal. Ia32-apt-get is a bandaid to tie people over till finally
multiarch comes. It is the best that can be done with mutliarch still
being blocked.
>> In synaptic Edit->"Reload package information" needs to be adapted and
>> Settings->Repositories.
>
> No. Adapting each and every APT frontend is not the way to go.
Adapting the backend is fine too and for the "update" part that might
totally suffice. But you won't be able to avoid patching
Settings->Repositories to know about multiarch. That is changing the
sources.list files so it will have to know about extensions to its
syntax.
Same with aptitude. The update part can most probably be done in
libapt but aptitudes peculiar depenency resolver will have to be
adapted too. That is what you get for writing your own.
And mind that I'm not talking about just ia32-apt-get but multiarch in
general.
Goswin von Brederlow
> On Mon, 29 Jun 2009, Goswin von Brederlow wrote:
>> Too bad they did that without involving the people already working on
>> multiarch via the alioth project.
>>
>> They messed up some finer details, broke the existing patches, made
>> the whole thing need a full release cycle for a transition due to
>> DEBIAN/control format changes and have a broen plan for -dev packages.
>>
>> Guillem Jover is also blocking the inclusion of already existing
>> patches for multiarch.
>
> I'm sorry but I have much more confidence in Guillem's and Steve's
> technical abilities than in yours.
Then maybe you also have some confidence in Tollef Fog Heen, Matt
Taggart, Anthony Towns, Aurelien Jarno. And hey, even Guillem Jover
itself. He did participate in the Informal multiarch meeting during
FOSDEM on 26/02/2006 in Brussels.
See the various links on http://wiki.debian.org/multiarch for the work
on multiarch going back to 2004.
> I can understand your frustration but you never offered a viable and clean
> long-term solution. Sending patches to dpkg to add/enable a Multi-Arch field
> without making use of it and/or explaining the whole plan and rationale
> is far from good.
>
> I would also not merge patches without knowing if the full plan is
> credible.
I wrote or updated patches that implement the design proposed over and
over again since 2004, talked about at debconf, documented in the wiki
and mailinglists. I asked Guillem Jover what he thinks is missing to
represent a viable and clean long-term solution. He is not interested
and I'm tired of posting the same information that has already been
posted.
This is not just my crazy ideas, I'm just fighting bit-rot.
> Cheers,
MfG
Goswin
Goswin von Brederlow
> Goswin von Brederlow wrote:
>
>> There where 3 options:
>>
>> 1) ia32-libs + ia32-libs-gtk (+ ia32-libs-kde + ia32-libs-qt)
>> ftp-master asked us to clean that up basically and
>> "it would not pass NEW if it where uploaded now"
>>
>> 2) ia32-lib* packages in the same schema as ia32-libs
>> vetoed by ftp-master for being way to many packages as ugly as
>> ia32-libs
>>
>> 3) ia32-apt-get
>>
>> So strike option 1 and 2 and what are you left with?
>
> Isn't it possible to have a system similar to apt-build?
>
> One would do "ia32-apt-convert ia32-libfoo" that would convert libfoo 32bits
/usr/lib/ia32-libs-tools/convert <amd64|ia64> libfoo_1.2-3_i386.deb
> package and its dependencies, put it in a local repository. Then the user
> could install ia32-libfoo with apt-get, aptitude, whatever.
apt-get install ia32-archive
It is probably slightly out of sync with ia32-apt-get because the
libc6-i386 upload forced a bit of a rush job on the latest changes but
if you look at it you get the idea.
Once I have time to verrify ia32-archive still works right and have
time to introduce an ia32-remote-archive dummy package I will probably
change ia32-libs to Depends: ia32-apt-get | ia32-archive |
ia32-remobe-archive.
> Yannick
>
> PS: Of course, there would be a ia32-apt-update to update all the ia32-*
> installed.
ia32-archive already has a hook in /etc/apt/apt-conf.d/ that does that
automatically on update.
MfG
Goswin
Steve Langasek
> Raphael Hertzog <her...@debian.org> writes:
> > There is work going on recently. Steve Langasek drafted a plan that he
> > wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by
> > Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a
> > reality inside Debian but I don't know of any timeframe.
> > https://wiki.ubuntu.com/MultiarchSpec
> They messed up some finer details, broke the existing patches,
Patches implementing what? I don't see any public discussion of an agreed
design for the package manager.
(Nor is there one for the MultiarchSpec, but that's only because Guillem and
I are still hammering out some of the details that we don't yet agree on; so
a public announcement is a little bit premature.)
> made the whole thing need a full release cycle for a transition due to
> DEBIAN/control format changes
You appear to be referring to
<https://wiki.ubuntu.com/MultiarchSpec#Extended%20semantics%20of%20per-architecture%20package%20relationships>.
What do you propose as an alternative that would let us achieve multiarch
sooner? Multiarch has already failed to get traction for more than two
release cycles, and I don't see that your ia32-apt-get kludges are doing
anything to get us there sooner.
Also, what are the immediate practical use cases for cross-arch depends on
extensible interpreters such as python and perl? Wine doesn't need this,
nor does nspluginwrapper AFAICS, so what actually is negatively impacted by
requiring that class of dependencies to be deferred by a release cycle?
> and have a broken plan for -dev packages.
Handling of -dev packages is defined as *out of scope* for this
specification. I fail to see how it's broken to confine the initial scope
to those elements that impact the package management tools, to avoid getting
bogged down in irrelevant discussions about filesystem layouts.
> Too bad they did that without involving the people already working on
> multiarch via the alioth project.
A project whose mailing list archive contains nothing but spam since 2006,
and whose primary proponent is also the author of ia32-apt-get? Yeah, not
really seeing how that would have been a win.
--
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/
slan...@ubuntu.com vor...@debian.org
Steve Langasek
> See the various links on http://wiki.debian.org/multiarch for the work
> on multiarch going back to 2004.
I reviewed that page prior to the UDS session.
It was all but useless (and I had to edit the page to update several links
which had gone dead).
It's an incoherent collection of links to everything anyone has ever said
about multiarch in public. Half of them are things that have been rejected
by one party or another. Nowhere on this page could I find any
specification of the package manager implementation aside from
<http://multiarch.alioth.debian.org/dpkg2.pdf>, which is a design that
hasn't gone anywhere (the proposer of this dpkg 2.0 design is no longer
involved in dpkg upstream).
So if that page is your evidence that there's a master plan that you're
working to: then no, there hasn't been.
--
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/
slan...@ubuntu.com vor...@debian.org
Didier 'OdyX' Raboud
> Didier 'OdyX' Raboud <did...@raboud.com> writes:
>> I would largely prefer if ia32-* in its actual shape would be released in
>> experimental (where, with this level of touching the base of Debian
>> repositories handling, it should sit) and version 2.7 uploaded back in
>> Sid...
>
> Conflicts with libc6-i386.
>
>> Regards,
>
> MfG
> Goswin
Hi Goswin,
As I see the thing, libc6-i386 Conflicts with everything shipping things in
/emul/.
What about fixing "just that" in a 1:2.8 upload to unstable ? You could then
upload your actual "18" series in experimental (2:19 then) where it should
obviously sit ?
Regards,
OdyX
Steve Langasek
> I've also CC'd Hector and Steve who are listed as owners on that
> document because whatever we do to get multiarch working (and I have no
> strong views on the right way to do it) we should definitely not do it
> differently to Ubuntu.
Since there seems to be some confusion on this point, let me clarify that
there is no proposal for Ubuntu to diverge from Debian in implementing
multiarch. A session on multiarch was held at UDS because it was
convenient for a face-to-face discussion of *Debian* package management.
Most of the people involved in the discussion were Debian developers,
including both a dpkg comaintainer (Guillem) and an apt comaintainer
(Michael). While the specification resides in the Ubuntu wiki, I'm
anticipating that the implementation will be driven directly in Debian
first, thanks in large part to Guillem's interest. And indeed, Ubuntu is
largely at Guillem's mercy, since no one in Ubuntu has committed any
resources to the dpkg implementation. :)
We also have a follow-up round table scheduled at DebConf, to take this
further:
https://penta.debconf.org/penta/submission/dc9/event/395
--
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/
slan...@ubuntu.com vor...@debian.org
Mark Brown
> Mark Brown <bro...@sirena.org.uk> writes:
> > There seems to be at least some crossover between the people who were
> > looking at multiarch and the people doing this stuff.
> But not the people blocking the inclusion of patches for multiarch
> already present in the BTS.
Then bring that up and try to move the discussion forward (as now seems
to be happening). The approach that's currently being pused seems like
a blind alley.
Goswin von Brederlow
> On Mon, Jun 29, 2009 at 09:31:24PM +0200, Goswin von Brederlow wrote:
>> Mark Brown <bro...@sirena.org.uk> writes:
>
>> > There seems to be at least some crossover between the people who were
>> > looking at multiarch and the people doing this stuff.
>
>> But not the people blocking the inclusion of patches for multiarch
>> already present in the BTS.
>
> Then bring that up and try to move the discussion forward (as now seems
> to be happening). The approach that's currently being pused seems like
> a blind alley.
People really do seem to confuse this. ia32-apt-get is not an
alternative to multiarch. Never has been, never will be.
It is the ugly hack that keeps existing things running till mutliarch
fixes the problem.
The only thing ia32-apt-get is supposed to fix is ia32-libs and
ia32-libs-gtk unmaintainability and security bugs.
MfG
Goswin
Goswin von Brederlow
> On Mon, Jun 29, 2009 at 09:50:01PM +0200, Goswin von Brederlow wrote:
>> Raphael Hertzog <her...@debian.org> writes:
>
>> > There is work going on recently. Steve Langasek drafted a plan that he
>> > wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by
>> > Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a
>> > reality inside Debian but I don't know of any timeframe.
>
>> > https://wiki.ubuntu.com/MultiarchSpec
>
>> They messed up some finer details, broke the existing patches,
>
> Patches implementing what? I don't see any public discussion of an agreed
> design for the package manager.
Patches for dpkg to accept the Multi-Arch field as a tristate of Yes,
No or missing and for packages to set that field. It's been
yes/no/missing in all the mails about multiarch for years and suddnely
you changed the string.
> (Nor is there one for the MultiarchSpec, but that's only because Guillem and
> I are still hammering out some of the details that we don't yet agree on; so
> a public announcement is a little bit premature.)
So you do that in a dark corner ignoring any other people that worked
on multiarch before? You are only 2 people, you only have 4 eyes (I
assume). You are bound to miss something that a larger group would
spot.
>> made the whole thing need a full release cycle for a transition due to
>> DEBIAN/control format changes
>
> You appear to be referring to
> <https://wiki.ubuntu.com/MultiarchSpec#Extended%20semantics%20of%20per-architecture%20package%20relationships>.
> What do you propose as an alternative that would let us achieve multiarch
> sooner? Multiarch has already failed to get traction for more than two
Look at perl for example:
Package: perl-base
Provides: perlapi-5.10.0
I suggest to also provide perlabi-$(DEB_HOST_GNU_TYPE) or
perlabi-5.10.0-$(DEB_HOST_GNU_TYPE). Perl extensions that need a
matching ABI can then easily depend on the right package.
The dh_perl helper could add the dependency automatically allowing a
binNMU to transition many packages.
> release cycles, and I don't see that your ia32-apt-get kludges are doing
> anything to get us there sooner.
Please stop confusing ia32-apt-get with multiarch. It clearly is a
kludge to keep 32bit binaries working till there is multiarch. It is
not ment as a replacement.
> Also, what are the immediate practical use cases for cross-arch depends on
> extensible interpreters such as python and perl? Wine doesn't need this,
> nor does nspluginwrapper AFAICS, so what actually is negatively impacted by
> requiring that class of dependencies to be deferred by a release cycle?
Say you have:
Package: foo
Architecture: amd64
Depends: perl
Package: bar
Architecture: i386
Depends: perl
Package: libbaz-perl
Architecture: amd64
Depends: perl
Package: libbat-perl
Architecture: i386
Depends: perl
Foo and Bar are binary packages that in some way use perl as a simple
interpreter. Libbaz-perl and libbat-perl on the other hand are
bindings for perl to use 2 C libraries libbaz and libbat.
Now with your proposal you have a few options:
1) perl has no Multi-Arch field
Eigther foo can be installed or bar. But never both.
2) perl has Multi-Arch: same
Now perl:i386 and perl:amd64 are flagged as coinstallable. Not
supported.
3) perl has Multi-Arch: foreign
Now foo and bar can be installed but so can libbaz-perl and
libbat-perl. One of the libs will be broken.
4) Using Depends: perl [same]
This would allos foo and bar to be both installed but only the
right one of libbaz-perl and libbat-perl. But that takes a release
cycle to introduce the new syntax.
Note that you also need perl to break libbaz-perl and libbat-perl
versions prior to the ones with "Depends: perl [same]" or yet
another release cycle. But a Provides: perlabi-$(DEB_HOST_GNU_TYPE)
suffers from the same problem.
>> and have a broken plan for -dev packages.
>
> Handling of -dev packages is defined as *out of scope* for this
> specification. I fail to see how it's broken to confine the initial scope
> to those elements that impact the package management tools, to avoid getting
> bogged down in irrelevant discussions about filesystem layouts.
Actually the filesystem layout for -dev packages is no problem at
all. We already have /usr/include/$(DEB_HOST_GNU_TYPE) for include
files (where needed) and /usr/lib/$(DEB_HOST_GNU_TYPE) for the *.so
links. That part might be work but not a problem.
The problem is in the dependencies and actually not restricted to just
-dev packages. Transitional/Meta packages suffer from this in
general. For the sake of an example lets say you have the following
packages (xlibs-dev being a real example):
Source: foo
Build-Depends: xlibs-dev, bar
Package: xlibs-dev
Architecture: all
Depends: libice-dev, libsm-dev, libx11-dev, libxext-dev, ...
Package: libice-dev
Architecture: any
Multi-Arch: same
Package: bar
Architecture: any
Multi-Arch: foreign
Depends: baz
Package: baz
Architecture: any
You assume:
| Dependencies, Build-Dependencies, and Recommends within an existing
| architecture foo will continue to remain closed over the set of
| packages declaring either Architecture: foo or Architecture: all.
Say you are building on amd64 and libice-dev:i386, bar:i386 and
baz:i386 is installed.
1) The 'Multi-Arch: foreign' breaks your assumption.
Bar:i386 + baz:i386 satisfy a dependency on bar for amd64 just
fine. You assumption would indicate you don't consider that a
satisfaction of the Build-Depends.
2) xlibs-dev being Architecture: all satisfies the Build-Depends
But libice-dev:i386 is the wrong package. Again the set is not
closed but this time that actualy is an error.
What actually needs to happen in this case is that the dependencies of
xlibs-dev need to be checked against the architecture (amd64) being
build for. Or more general the architecture of the package requesting
a dependency check. So on Architecture: all packages you have to
recursively check the depends.
But not always. Say you have a package buzz that just contains a few
bash scripts and is in the dependency chain somwhere. A bash:amd64
should satsify for a dependency on buzz from both an amd64 package and
i386 package.
The problem is you have no way of specifying which of the two cases
apply in the Architecture: all package, because:
| Setting the Multi-Arch field on a package which is Architecture: all
| is considered an error. dpkg-deb must refuse to generate a .deb with
| this combination of values. Behavior when trying to install such a
| package is undefined.
If you drop that and allow Architecture: all packages to carry a
Multi-Arch field you can say the following:
An Architecture: all package with 'Multi-Arch: same' is only
considered installed for a package of architecture XXX if all its
dependencies (Depends, Conflicts, ...) are also satisfied for
architecture XXX. Dependencies are checked recursively.
An Architecture: all package with 'Multi-Arch: foreign' is considered
installed for packages of any architecture.
An Architecture: all package without Multi-Arch field could be either
or. Recursively checking dependencies would be the safe option.
Acepting it as 'foreign' is the more practical one but would initialy
allow broken dependency trees.
This is something I noticed while working on a multiarch dpkg and
ia32-apt-get. I actually did run into this case with xlibs-dev.
>> Too bad they did that without involving the people already working on
>> multiarch via the alioth project.
>
> A project whose mailing list archive contains nothing but spam since 2006,
> and whose primary proponent is also the author of ia32-apt-get? Yeah, not
> really seeing how that would have been a win.
Because everything was blocked by the toolchain. Gcc only recently was
fixed to fully support /usr/lib/$(DEB_HOST_GNU_TYPE)/. There wasn't
really anything to discuss or do.
All I'm saying is that it would have been nice to drop a note on the
ML or the wiki about your intention to see if any of the old people
want to contribute too.
MfG
Goswin
Josselin Mouette
> Please stop confusing ia32-apt-get with multiarch. It clearly is a
> kludge to keep 32bit binaries working till there is multiarch. It is
> not ment as a replacement.
No, it is not a kludge. It is a horrible pile of trash.
ia32-libs, in the state it was before you broke it, was a kludge. One
that we can live with until multiarch is ready.
Now if you could just revert the changes in ia32-libs and spend the time
you are currently wasting on ia32-apt-get helping with multiarch, that
would be more helpful.
Thanks,
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
Mark Brown
> Mark Brown <bro...@sirena.org.uk> writes:
> > Then bring that up and try to move the discussion forward (as now seems
> > to be happening). The approach that's currently being pused seems like
> > a blind alley.
> People really do seem to confuse this. ia32-apt-get is not an
> alternative to multiarch. Never has been, never will be.
It looks awfully like a bodged version of multiarch - doing what you're
doing and installing i386 packages on amd64 appears to be one of the
biggest use cases for multiarch, after all.
Goswin von Brederlow
> On Mon, Jun 29, 2009 at 09:02:05PM +0100, Matthew Johnson wrote:
>> I've also CC'd Hector and Steve who are listed as owners on that
>> document because whatever we do to get multiarch working (and I have no
>> strong views on the right way to do it) we should definitely not do it
>> differently to Ubuntu.
>
> Since there seems to be some confusion on this point, let me clarify that
> there is no proposal for Ubuntu to diverge from Debian in implementing
> multiarch. A session on multiarch was held at UDS because it was
> convenient for a face-to-face discussion of *Debian* package management.
> Most of the people involved in the discussion were Debian developers,
> including both a dpkg comaintainer (Guillem) and an apt comaintainer
> (Michael). While the specification resides in the Ubuntu wiki, I'm
> anticipating that the implementation will be driven directly in Debian
> first, thanks in large part to Guillem's interest. And indeed, Ubuntu is
> largely at Guillem's mercy, since no one in Ubuntu has committed any
> resources to the dpkg implementation. :)
>
> We also have a follow-up round table scheduled at DebConf, to take this
> further:
>
> https://penta.debconf.org/penta/submission/dc9/event/395
Thanks for clarifying that. Didn't sound like that before.
Do you have any minutes of the meeting you could include in the
debian wiki?
It probably wouldn't hurt to put the proposal there too and update it
as more details are cleared up?
MfG
Goswin
Goswin von Brederlow
> Le mardi 30 juin 2009 à 18:52 +0200, Goswin von Brederlow a écrit :
>> Please stop confusing ia32-apt-get with multiarch. It clearly is a
>> kludge to keep 32bit binaries working till there is multiarch. It is
>> not ment as a replacement.
>
> No, it is not a kludge. It is a horrible pile of trash.
>
> ia32-libs, in the state it was before you broke it, was a kludge. One
> that we can live with until multiarch is ready.
ftp-master disagreed.
> Now if you could just revert the changes in ia32-libs and spend the time
> you are currently wasting on ia32-apt-get helping with multiarch, that
> would be more helpful.
>
> Thanks,
I didn't change anything in ia32-libs. It was replaced completly. So
just checkout ia32-libs from svn, increase the version and upload. But
then you have to maintain it and do security support for it too.
Steve Langasek
> Thanks for clarifying that. Didn't sound like that before.
> Do you have any minutes of the meeting you could include in the
> debian wiki?
The spec is the synthesis of what was discussed during the meeting. The
live minutes can also be found on gobby.ubuntu.com
(fountations-karmic-multiarch-support), but I don't expect there to be
anything of interest there.
> It probably wouldn't hurt to put the proposal there too and update it
> as more details are cleared up?
Yes, it would. We don't need to have two copies of the spec in two
different wikis. The current URL is already referenced in other places;
please just link to this page from wiki.debian.org/multiarch (if you think
it's appropriate), and when things are finalized we can move it to a more
permanent, less wiki-y location.
--
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/
slan...@ubuntu.com vor...@debian.org
Steve Langasek
> > Patches implementing what? I don't see any public discussion of an agreed
> > design for the package manager.
> Patches for dpkg to accept the Multi-Arch field as a tristate of Yes,
> No or missing and for packages to set that field. It's been
> yes/no/missing in all the mails about multiarch for years and suddnely
> you changed the string.
Based on feedback from Guillem as dpkg maintainer (among others). It does
no good to have a spec that's stable for years if it gains no traction with
the maintainers of the packages where it has to be implemented.
> >> made the whole thing need a full release cycle for a transition due to
> >> DEBIAN/control format changes
> > You appear to be referring to
> > <https://wiki.ubuntu.com/MultiarchSpec#Extended%20semantics%20of%20per-architecture%20package%20relationships>.
> > What do you propose as an alternative that would let us achieve multiarch
> > sooner? Multiarch has already failed to get traction for more than two
> Look at perl for example:
> Package: perl-base
> Provides: perlapi-5.10.0
> I suggest to also provide perlabi-$(DEB_HOST_GNU_TYPE) or
> perlabi-5.10.0-$(DEB_HOST_GNU_TYPE). Perl extensions that need a
> matching ABI can then easily depend on the right package.
> The dh_perl helper could add the dependency automatically allowing a
> binNMU to transition many packages.
Do you intend to do the same for python, which has no such "API" provides?
Or are you only proposing a workaround for perl?
> > Also, what are the immediate practical use cases for cross-arch depends on
> > extensible interpreters such as python and perl? Wine doesn't need this,
> > nor does nspluginwrapper AFAICS, so what actually is negatively impacted by
> > requiring that class of dependencies to be deferred by a release cycle?
> Say you have:
> Package: foo
> Architecture: amd64
> Depends: perl
> Package: bar
> Architecture: i386
> Depends: perl
> Package: libbaz-perl
> Architecture: amd64
> Depends: perl
> Package: libbat-perl
> Architecture: i386
> Depends: perl
This is a hypothetical. I asked for evidence of a *practical* impact.
> 4) Using Depends: perl [same]
> This would allos foo and bar to be both installed but only the
> right one of libbaz-perl and libbat-perl. But that takes a release
> cycle to introduce the new syntax.
But if it's unproven that anyone *needs* this, there's no reason to worry
about the delay for implementing this corner case.
> Note that you also need perl to break libbaz-perl and libbat-perl
> versions prior to the ones with "Depends: perl [same]" or yet
> another release cycle. But a Provides: perlabi-$(DEB_HOST_GNU_TYPE)
> suffers from the same problem.
The need for flag days for interpreters is identified as a limitation of
this design, and is actually a point that's currently under review.
> > Handling of -dev packages is defined as *out of scope* for this
> > specification. I fail to see how it's broken to confine the initial scope
> > to those elements that impact the package management tools, to avoid getting
> > bogged down in irrelevant discussions about filesystem layouts.
> The problem is in the dependencies and actually not restricted to just
> -dev packages. Transitional/Meta packages suffer from this in
> general. For the sake of an example lets say you have the following
> packages (xlibs-dev being a real example):
You know xlibs-dev is no longer in the archive, right?
-dev metapackages don't make a whole lot of sense except on a transitional
basis. While there may be some things that still need to be tightened up
here, if one of the outcomes is that -dev metapackages have to be made arch:
any, I don't think that's too onerous.
> Source: foo
> Build-Depends: xlibs-dev, bar
> Package: xlibs-dev
> Architecture: all
> Depends: libice-dev, libsm-dev, libx11-dev, libxext-dev, ...
> Package: libice-dev
> Architecture: any
> Multi-Arch: same
> Package: bar
> Architecture: any
> Multi-Arch: foreign
> Depends: baz
> Package: baz
> Architecture: any
> You assume:
> | Dependencies, Build-Dependencies, and Recommends within an existing
> | architecture foo will continue to remain closed over the set of
> | packages declaring either Architecture: foo or Architecture: all.
This is a statement of the implications for the archive, and is an
expression of the existing archive requirements. It says nothing about how
build-dependency fields are to be interpreted on a build system.
> Say you are building on amd64 and libice-dev:i386, bar:i386 and
> baz:i386 is installed.
> 1) The 'Multi-Arch: foreign' breaks your assumption.
> Bar:i386 + baz:i386 satisfy a dependency on bar for amd64 just
> fine. You assumption would indicate you don't consider that a
> satisfaction of the Build-Depends.
Per the above, your conclusion here is invalid. It satisfies the
build-depends, it's just not sufficient from an archive perspective for
bar:i386 to be the *only* package in the archive that satisfies this
build-dependency; and this is not the bar that will be used by the buildds.
> 2) xlibs-dev being Architecture: all satisfies the Build-Depends
> But libice-dev:i386 is the wrong package. Again the set is not
> closed but this time that actualy is an error.
> What actually needs to happen in this case is that the dependencies of
> xlibs-dev need to be checked against the architecture (amd64) being
> build for. Or more general the architecture of the package requesting
> a dependency check. So on Architecture: all packages you have to
> recursively check the depends.
This points out that more attention may need to be given to how
any->all->any transitive dependencies are handled, yes.
> But not always. Say you have a package buzz that just contains a few
> bash scripts and is in the dependency chain somwhere. A bash:amd64
> should satsify for a dependency on buzz from both an amd64 package and
> i386 package.
Which is expressed by making bash Multi-Arch: foreign, truncating the
recursive architecture enforcement.
> | Setting the Multi-Arch field on a package which is Architecture: all
> | is considered an error. dpkg-deb must refuse to generate a .deb with
> | this combination of values. Behavior when trying to install such a
> | package is undefined.
> If you drop that and allow Architecture: all packages to carry a
> Multi-Arch field you can say the following:
> An Architecture: all package with 'Multi-Arch: same' is only
> considered installed for a package of architecture XXX if all its
> dependencies (Depends, Conflicts, ...) are also satisfied for
> architecture XXX. Dependencies are checked recursively.
> An Architecture: all package with 'Multi-Arch: foreign' is considered
> installed for packages of any architecture.
> An Architecture: all package without Multi-Arch field could be either
> or. Recursively checking dependencies would be the safe option.
> Acepting it as 'foreign' is the more practical one but would initialy
> allow broken dependency trees.
This is also an option, but I think only transitively enforcing the
same-arch requirement for dependencies is sufficient to solve the problem
and yields a simpler outcome.
--
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/
slan...@ubuntu.com vor...@debian.org
Goswin von Brederlow
> On Tue, Jun 30, 2009 at 06:52:34PM +0200, Goswin von Brederlow wrote:
>> Look at perl for example:
>
>> Package: perl-base
>> Provides: perlapi-5.10.0
>
>> I suggest to also provide perlabi-$(DEB_HOST_GNU_TYPE) or
>> perlabi-5.10.0-$(DEB_HOST_GNU_TYPE). Perl extensions that need a
>> matching ABI can then easily depend on the right package.
>
>> The dh_perl helper could add the dependency automatically allowing a
>> binNMU to transition many packages.
>
> Do you intend to do the same for python, which has no such "API" provides?
> Or are you only proposing a workaround for perl?
Yes. No.
I was using perl as example because it verry nearly already is doing
this with its perlapi-5.10.0 provide.
I imagine dh_python / dh_pycentral / dh_pysupport will be able to
autodetect the need for a dependency on the python ABI automatically
as well.
>> > Also, what are the immediate practical use cases for cross-arch depends on
>> > extensible interpreters such as python and perl? Wine doesn't need this,
>> > nor does nspluginwrapper AFAICS, so what actually is negatively impacted by
>> > requiring that class of dependencies to be deferred by a release cycle?
>
>> Say you have:
>
>> Package: foo
>> Architecture: amd64
>> Depends: perl
>
>> Package: bar
>> Architecture: i386
>> Depends: perl
>
>> Package: libbaz-perl
>> Architecture: amd64
>> Depends: perl
>
>> Package: libbat-perl
>> Architecture: i386
>> Depends: perl
>
> This is a hypothetical. I asked for evidence of a *practical* impact.
You really need me to go through the rdpends of interpreters and find
an example of 2 arch:any packages that depend on one? Ok, here we go:
Package: skyped
Architecture: i386
Depends: python (>= 2.5), python-gnutls, python-skype (>= 0.9.28.7)
Description: Daemon to control Skype remotely
Package: totem
Architecture: amd64
Depends: python, python-support (>= 0.90.0)
Description: A simple media player for the GNOME desktop based on GStreamer
So installing skyped would require a 32bit python and 32bit totem
prior to a release cycle.
>> 4) Using Depends: perl [same]
>> This would allos foo and bar to be both installed but only the
>> right one of libbaz-perl and libbat-perl. But that takes a release
>> cycle to introduce the new syntax.
>
> But if it's unproven that anyone *needs* this, there's no reason to worry
> about the delay for implementing this corner case.
See above.
>> Note that you also need perl to break libbaz-perl and libbat-perl
>> versions prior to the ones with "Depends: perl [same]" or yet
>> another release cycle. But a Provides: perlabi-$(DEB_HOST_GNU_TYPE)
>> suffers from the same problem.
>
> The need for flag days for interpreters is identified as a limitation of
> this design, and is actually a point that's currently under review.
>
>> > Handling of -dev packages is defined as *out of scope* for this
>> > specification. I fail to see how it's broken to confine the initial scope
>> > to those elements that impact the package management tools, to avoid getting
>> > bogged down in irrelevant discussions about filesystem layouts.
>
>> The problem is in the dependencies and actually not restricted to just
>> -dev packages. Transitional/Meta packages suffer from this in
>> general. For the sake of an example lets say you have the following
>> packages (xlibs-dev being a real example):
>
> You know xlibs-dev is no longer in the archive, right?
>
> -dev metapackages don't make a whole lot of sense except on a transitional
> basis. While there may be some things that still need to be tightened up
> here, if one of the outcomes is that -dev metapackages have to be made arch:
> any, I don't think that's too onerous.
Not just -dev metapackages, any meta/transitional packages can run
into this. xlibs-dev is just the package where I noticed the issue
first.
That was all I was saying.
>> But not always. Say you have a package buzz that just contains a few
>> bash scripts and is in the dependency chain somwhere. A bash:amd64
>> should satsify for a dependency on buzz from both an amd64 package and
>> i386 package.
>
> Which is expressed by making bash Multi-Arch: foreign, truncating the
> recursive architecture enforcement.
Not always possible or feasable. You will probably call it another
unproven corner case but imagine an architecture all package that
depends on perl and some perl bindings for a library. The bindings
can't be Multi-Arch: foreign.
Lets see, what do we have in that regard?
An arch:all package depending on an interpreter and bindings:
angrydd, balazar, balazarbrothers, bouncy, bubbros, cappuccino,
castle-combat, ... is there any python game not falling into that
category?
ggz-kde-client -> ggz-python-games -> python-pygame
There is your corner case.
A selective recurison for an any->all->any dependencie would be
usefull I believe.
>> | Setting the Multi-Arch field on a package which is Architecture: all
>> | is considered an error. dpkg-deb must refuse to generate a .deb with
>> | this combination of values. Behavior when trying to install such a
>> | package is undefined.
>
>> If you drop that and allow Architecture: all packages to carry a
>> Multi-Arch field you can say the following:
>
>> An Architecture: all package with 'Multi-Arch: same' is only
>> considered installed for a package of architecture XXX if all its
>> dependencies (Depends, Conflicts, ...) are also satisfied for
>> architecture XXX. Dependencies are checked recursively.
>
>> An Architecture: all package with 'Multi-Arch: foreign' is considered
>> installed for packages of any architecture.
>
>> An Architecture: all package without Multi-Arch field could be either
>> or. Recursively checking dependencies would be the safe option.
>> Acepting it as 'foreign' is the more practical one but would initialy
>> allow broken dependency trees.
>
> This is also an option, but I think only transitively enforcing the
> same-arch requirement for dependencies is sufficient to solve the problem
> and yields a simpler outcome.
It would be well defined but less powerfull/flexible.
MfG
Goswin