Re: ia32-libs depends on ia32-apt-get ?
Steve Langasek vor...@debian.org writes: 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. 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
Re: ia32-libs depends on ia32-apt-get ?
Goswin von Brederlow wrote: 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Multiarch (Was: Re: ia32-libs depends on ia32-apt-get)
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 -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Mon, Jun 29, 2009 at 09:31:24PM +0200, Goswin von Brederlow wrote: Mark Brown broo...@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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Steve Langasek vor...@debian.org writes: On Mon, Jun 29, 2009 at 09:50:01PM +0200, Goswin von Brederlow wrote: Raphael Hertzog hert...@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
Re: ia32-libs depends on ia32-apt-get ?
Mark Brown broo...@sirena.org.uk writes: On Mon, Jun 29, 2009 at 09:31:24PM +0200, Goswin von Brederlow wrote: Mark Brown broo...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
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. 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 signature.asc Description: Ceci est une partie de message numériquement signée
Re: ia32-libs depends on ia32-apt-get ?
On Tue, Jun 30, 2009 at 06:56:11PM +0200, Goswin von Brederlow wrote: Mark Brown broo...@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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Josselin Mouette j...@debian.org writes: 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. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Tue, Jun 30, 2009 at 06:52:34PM +0200, Goswin von Brederlow wrote: 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
Re: ia32-libs depends on ia32-apt-get ?
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 - 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 prein...@logic.atVienna University of Technology Debian Developer prein...@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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
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.
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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Mo, 29 Jun 2009, Didier 'OdyX' Raboud wrote: 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 prein...@logic.atVienna University of Technology Debian Developer prein...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Didier 'OdyX' Raboud did...@raboud.com writes:
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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Le lundi 29 juin 2009 à 11:54 +0200, Goswin von Brederlow a écrit : The reasons for ia32-apt-get are this: [snip] 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 : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: ia32-libs depends on ia32-apt-get ?
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 :
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,
--
Didier Raboud, proud Debian user.
CH-1802 Corseaux
did...@raboud.com
apt_sources_list_d_after.tar.bz2
Description: application/bzip-compressed-tar
apt_sources_list_d.tar.bz2
Description: application/bzip-compressed-tar
Re: ia32-libs depends on ia32-apt-get ?
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 :
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)
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.
- 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...
Conflicts with libc6-i386.
Regards,
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe.
Re: ia32-libs depends on ia32-apt-get ?
Goswin von Brederlow wrote:
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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Didier Raboud did...@raboud.com writes:
Goswin von Brederlow wrote:
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.
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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Le lundi 29 juin 2009 à 15:14 +0200, Goswin von Brederlow a écrit : 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 : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: ia32-libs depends on ia32-apt-get ?
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. The issue is I don't remember for sure what /etc/apt/sources.list looked like before the upgrade, but now it is: lion...@harif:/etc/apt$ cat preferences Package: * Pin: release a=testing Pin-Priority: 600 lion...@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 lion...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Le lundi 29 juin 2009 à 15:33 +0200, Hans-J. Ullrich a écrit : 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, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: ia32-libs depends on ia32-apt-get ?
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. The issue is I don't remember for sure what /etc/apt/sources.list looked like before the upgrade, but now it is: lion...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Josselin Mouette j...@debian.org (29/06/2009): 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. signature.asc Description: Digital signature
Re: ia32-libs depends on ia32-apt-get ?
On Mon, Jun 29, 2009 at 03:57:28PM +0200, Goswin von Brederlow wrote: 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: lion...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
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? 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Mehdi Dogguy mehdi.dog...@pps.jussieu.fr writes: 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
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. How would aptitude users do now? apt-get update; aptitude And how would synaptic users do? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: ia32-libs depends on ia32-apt-get ?
Lionel Elie Mamane lio...@mamane.lu writes: On Mon, Jun 29, 2009 at 03:57:28PM +0200, Goswin von Brederlow wrote: 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. 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: lion...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Mon, Jun 29, 2009 at 17:30:35 +0200, 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? Figure out an acceptable option 4. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Mon, Jun 29, 2009 at 05:59:32PM +0200, Julien Cristau wrote: 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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
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. Best wishes Norbert --- Dr. Norbert Preining prein...@logic.atVienna University of Technology Debian Developer prein...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
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, -- 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/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Mon Jun 29 20:18, Raphael Hertzog wrote: 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 signature.asc Description: Digital signature
Re: ia32-libs depends on ia32-apt-get ?
Josselin Mouette j...@debian.org writes: 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. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Mark Brown broo...@sirena.org.uk writes: 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Le lundi 29 juin 2009 à 21:30 +0200, Goswin von Brederlow a écrit : Josselin Mouette j...@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. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: ia32-libs depends on ia32-apt-get ?
Raphael Hertzog hert...@debian.org writes: 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Multiarch (Was: Re: ia32-libs depends on ia32-apt-get)
On Mon Jun 29 21:50, Goswin von Brederlow wrote: 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. signature.asc Description: Digital signature
Re: ia32-libs depends on ia32-apt-get ?
Goswin von Brederlow wrote: 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
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 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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Mon, Jun 29, 2009 at 05:30:35PM +0200, Goswin von Brederlow wrote: Mehdi Dogguy mehdi.dog...@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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
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. 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/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Le lundi 29 juin 2009 à 23:06 +0200, Raphael Hertzog a écrit : 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. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: ia32-libs depends on ia32-apt-get ?
Josselin Mouette j...@debian.org writes: Le lundi 29 juin 2009 à 21:30 +0200, Goswin von Brederlow a écrit : Josselin Mouette j...@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 guil...@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. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Raphael Hertzog hert...@debian.org writes: 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Yannick yannick.roeh...@free.fr writes: 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Mon, Jun 29, 2009 at 09:50:01PM +0200, Goswin von Brederlow wrote: Raphael Hertzog hert...@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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
On Tue, Jun 30, 2009 at 05:43:16AM +0200, Goswin von Brederlow wrote: 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
