Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
On Fri, Apr 03, 2009 at 11:50:45PM +0200, Goswin von Brederlow wrote: > Cyril Brulebois writes: > > > Vincent Fourmond (01/04/2009): > >> Although I admit that schroot is a neat tool to deal with that, it is > >> overkill in the case of wine, and much too complex for users that would > >> be interested to use wine: one of the public that can be attracted to > >> the GNU/Linux side of the game is gamers - especially now that there are > >> so many *recent* games that work with it. Telling them: «well, you'll > >> have to build a ia32 chroot to play...» is likely to drive them off for > >> good. > > > > I can't really see why wine couldn't embed a script to do the needed > > work. Users would need to call a single command to prepare the > > environment. It could, I guess, even be done in the postinst. > > So wine on amd64 should be a dummy package that then creates a 32bit > chroot all on its own? > > Now what about rar? Another chroot? And the 32-bit application can't launch 64-bit applications as it could if it were just running with 32-bit libraries outside of a chroot. The chroot is too isolating. I used to run 32-bit Firefox in a chroot before 64-bit flash and nspluginwrapper etc and of course it couldn't launch external applications associated with various file types etc. PITA. Hamish -- Hamish Moffatt VK3SB -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Cyril Brulebois writes: > Vincent Fourmond (01/04/2009): >> Although I admit that schroot is a neat tool to deal with that, it is >> overkill in the case of wine, and much too complex for users that would >> be interested to use wine: one of the public that can be attracted to >> the GNU/Linux side of the game is gamers - especially now that there are >> so many *recent* games that work with it. Telling them: «well, you'll >> have to build a ia32 chroot to play...» is likely to drive them off for >> good. > > I can't really see why wine couldn't embed a script to do the needed > work. Users would need to call a single command to prepare the > environment. It could, I guess, even be done in the postinst. > > Mraw, > KiBi. So wine on amd64 should be a dummy package that then creates a 32bit chroot all on its own? Now what about rar? Another chroot? And what about all the 3rd party debs? They certianly won't provide a "build me a chroot" debs. Or what about changes in /etc/resolve.conf? Suddenly you need to run a dns proxy so the chroot has internet access even if your dsl modem redials and gets a new nameserver. A 32 bit chroot is something a user can create but not something you can package up reasonably clean. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Vincent Fourmond (01/04/2009): > Although I admit that schroot is a neat tool to deal with that, it is > overkill in the case of wine, and much too complex for users that would > be interested to use wine: one of the public that can be attracted to > the GNU/Linux side of the game is gamers - especially now that there are > so many *recent* games that work with it. Telling them: «well, you'll > have to build a ia32 chroot to play...» is likely to drive them off for > good. I can't really see why wine couldn't embed a script to do the needed work. Users would need to call a single command to prepare the environment. It could, I guess, even be done in the postinst. Mraw, KiBi. signature.asc Description: Digital signature
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
[...] > > I'm unsure why we need *any* 32-bit libraries or binaries on an > amd64 system. If one needs to run 32-bit software, it is possible to > debootstrap an i386 system and use it as a chroot. Using a tool such > as schroot handles all of the kernel personality and chroot details, > and even allows normal users to use it with access to all their files, > etc. With a few one line scripts/shell aliases, it's completely > transparent. It also has the advantage of being a complete i386 > system rather than just a collection of libraries; you can keep it up > to date using the usual tools, and even boot it if you desire. i.e. > you get all the normal security support and updates. > > With multiarch, it's a different story, but we aren't quite there yet. > My main use of 32-bit libraries is commercial software that is available for 32bit systems only. Yes, that's bad, but I can't do anything about that ATM. I'd really hate to run (and maintain!) an additional chroot on each of those servers just to run a single application. I do have i386 schroots on other systems, but I prefer not to maintain that on each and every server. It might actually be a bit of problem, because one of those commercial products is our backup software... Best, Michael pgpuxu7YoZpem.pgp Description: PGP signature
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Roger Leigh wrote: > [...] > I'm unsure why we need *any* 32-bit libraries or binaries on an > amd64 system. If one needs to run 32-bit software, it is possible to > debootstrap an i386 system and use it as a chroot. The best example that comes to my mind is wine. You definitely have to run it as 32 bits code, and it therefore depends on 32 bit libraries. > Using a tool such > as schroot handles all of the kernel personality and chroot details, > and even allows normal users to use it with access to all their files, > etc. With a few one line scripts/shell aliases, it's completely > transparent. It also has the advantage of being a complete i386 > system rather than just a collection of libraries; you can keep it up > to date using the usual tools, and even boot it if you desire. i.e. > you get all the normal security support and updates. Although I admit that schroot is a neat tool to deal with that, it is overkill in the case of wine, and much too complex for users that would be interested to use wine: one of the public that can be attracted to the GNU/Linux side of the game is gamers - especially now that there are so many *recent* games that work with it. Telling them: «well, you'll have to build a ia32 chroot to play...» is likely to drive them off for good. Just for the record, I personally have ia32 chroots for various reasons, but I run wine directly from my amd64 system, because it is way more comfortable this way. Cheers, Vincent -- Vincent Fourmond, Debian Developer http://vince-debian.blogspot.com/ The Librarian was, of course, very much in favour of reading in general, but readers in particular got on his nerves. -- Terry Pratchet, Men at arms Vincent, listening to Enfer et paradis (Les Negresses Vertes) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Goswin von Brederlow wrote: > Luk Claes writes: > >> Goswin von Brederlow wrote: >>> Adeodato Simó writes: >>> * Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]: Mark Hymers has talked about providing a mechanism to ensure source packages stay on the pool when other stuff has been built from them (eg. kernel module packages). With this, ia32-libs could become a small source package containing scripts that would download the necessary binary packages at build time, and would encode in a header the employed versions; then, source for those versions would not be removed from the pool. >>> Buildds don't have internet access in their build >>> environment. ia32-libs may not download anything at build time. Plus >>> rebuilding would give widely unreproducible results. >> AFAIK you're talking about 2 architectures, so building them in another >> way than on the buildds should not be hard. >> >> I guess you mean unpredictable instead of unreproducible as building >> with the same versions as mentioned in the build log should be >> reproducible or ia32-libs better just gets removed from the archive >> altogether... Why would it be unpredictable, what issues do you see? > > unpredictable yes. The problem is that downloading packagescan fail > for any number of reasons and gets different versions between > builds. Verry unpredictable. > > And until there is a way for a deb to force DAK to keep other source > packages available ia32-libs would quickly violate the GPL (binary > without source). I don't see that magic feature comming anytime soon > given how slow DAK changes. Till it does the above is just not an option. Your answering to a post where an ftp-master proposal is mentioned to change dak to make it possible... as otherwise it will just be removed from the archive AFAICS... Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Peter Samuelson writes: > [Goswin von Brederlow] >> Currently ia32-libs source builds one ia32-libs.deb. Not split up per >> binary package it contains. > > Yes but I thought we were talking about changing that, so that it > builds ia32-libc6, ia32-libssl0.9.8, etc. That is how I understood > Dato's proposal, which I think is probably the most sensible solution > I have seen so far. > >> And yes, uploading a new source that builds a deb with the same >> version as the last source will cause DAK to reject the upload. > > That's a problem, then. Avoidable by splitting the source package and not just building seperate debs. The problem with the solution is that ftpmaster would reject the 50+ new source packages for ia32-lib* because of the source duplication. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Matthew Johnson writes: > On Mon Mar 30 17:20, Roger Leigh wrote: >> With multiarch, it's a different story, but we aren't quite there yet. >> > Multiarch is definitely the right way to handle this and I think we > should were possible be putting effort into that and not hacks. > > I still am not clear what the holdups are with multiarch. What is there > that people like myself and the ia32-libs guys can do to get it working? > > I would really like to see it in squeeze if that's possible. > > Matt Put pressure on the gcc maintainers. After years the toolchain is still not ready to link against libraries in multiarch dirs without adding -L options manually. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Luk Claes writes: > Goswin von Brederlow wrote: >> Adeodato Simó writes: >> >>> * Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]: > >>> Mark Hymers has talked about providing a mechanism to ensure source >>> packages stay on the pool when other stuff has been built from them (eg. >>> kernel module packages). With this, ia32-libs could become a small >>> source package containing scripts that would download the necessary >>> binary packages at build time, and would encode in a header the employed >>> versions; then, source for those versions would not be removed from the >>> pool. >> >> Buildds don't have internet access in their build >> environment. ia32-libs may not download anything at build time. Plus >> rebuilding would give widely unreproducible results. > > AFAIK you're talking about 2 architectures, so building them in another > way than on the buildds should not be hard. > > I guess you mean unpredictable instead of unreproducible as building > with the same versions as mentioned in the build log should be > reproducible or ia32-libs better just gets removed from the archive > altogether... Why would it be unpredictable, what issues do you see? unpredictable yes. The problem is that downloading packagescan fail for any number of reasons and gets different versions between builds. Verry unpredictable. And until there is a way for a deb to force DAK to keep other source packages available ia32-libs would quickly violate the GPL (binary without source). I don't see that magic feature comming anytime soon given how slow DAK changes. Till it does the above is just not an option. >> Currently the size makes regular uploads too costly imho. And the >> security team is still not supporting ia32-libs. I even did prepare an >> security upload for etch last year that they only had to sponsor but >> never heard back from the team. > > A good reason to not just shoot any proposal to make that easier IMHO. > > Cheers > > Luk MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Adeodato Simó writes: >> Currently the size makes regular uploads too costly imho. And the >> security team is still not supporting ia32-libs. I even did prepare an >> security upload for etch last year that they only had to sponsor but >> never heard back from the team. > > With my proposed hack, the upload size would be just the binary > packages, since the source would not be duplicated. Surely the Security > Team can cope with that, if they so wish. (And/or if the package would > have an arch:all package, eg. with scripts, you can get away with > uploading only that one.) Which would leave the task of having to check for updates, update the source, build, sign, upload. And at least the sign part can not be automated. And even with perfect responce times that still means one day delay. And when ever is responce time perfect? > P.S.: In case it isnât clear already, my only goal is that the hack we > may have in place while we get multiarch, is an acceptable one. I would > really like for it to be in place as little time as possible. At the current rate that is still years. :( > 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: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Goswin von Brederlow wrote: > Adeodato Simó writes: > >> * Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]: >> Mark Hymers has talked about providing a mechanism to ensure source >> packages stay on the pool when other stuff has been built from them (eg. >> kernel module packages). With this, ia32-libs could become a small >> source package containing scripts that would download the necessary >> binary packages at build time, and would encode in a header the employed >> versions; then, source for those versions would not be removed from the >> pool. > > Buildds don't have internet access in their build > environment. ia32-libs may not download anything at build time. Plus > rebuilding would give widely unreproducible results. AFAIK you're talking about 2 architectures, so building them in another way than on the buildds should not be hard. I guess you mean unpredictable instead of unreproducible as building with the same versions as mentioned in the build log should be reproducible or ia32-libs better just gets removed from the archive altogether... Why would it be unpredictable, what issues do you see? > Currently the size makes regular uploads too costly imho. And the > security team is still not supporting ia32-libs. I even did prepare an > security upload for etch last year that they only had to sponsor but > never heard back from the team. A good reason to not just shoot any proposal to make that easier IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
* Goswin von Brederlow [Mon, 30 Mar 2009 18:00:08 +0200]: > The alternative solution is ia32-archive, which creates a local > repository of converted packages on the users system. No wrappers > needed and no ugly hacks but that comes at the cost of disk space and > the need to configure what packages to convert (converting just > everything would cost too much disk). Right, and I think that’s suboptimal from an useability POV: `apt-get install wine` should work on amd64 out of the box, without needing to do extra work, IMHO. > Buildds don't have internet access in their build > environment. ia32-libs may not download anything at build time. I guess when you replied to this you hadn’t gotten to the part where I said ia32-libs would be a “package with special needs”. > Plus rebuilding would give widely unreproducible results. Would behave the same as other packages already do (linux modules, installer). > Currently the size makes regular uploads too costly imho. And the > security team is still not supporting ia32-libs. I even did prepare an > security upload for etch last year that they only had to sponsor but > never heard back from the team. With my proposed hack, the upload size would be just the binary packages, since the source would not be duplicated. Surely the Security Team can cope with that, if they so wish. (And/or if the package would have an arch:all package, eg. with scripts, you can get away with uploading only that one.) P.S.: In case it isn’t clear already, my only goal is that the hack we may have in place while we get multiarch, is an acceptable one. I would really like for it to be in place as little time as possible. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
[Goswin von Brederlow] > Currently ia32-libs source builds one ia32-libs.deb. Not split up per > binary package it contains. Yes but I thought we were talking about changing that, so that it builds ia32-libc6, ia32-libssl0.9.8, etc. That is how I understood Dato's proposal, which I think is probably the most sensible solution I have seen so far. > And yes, uploading a new source that builds a deb with the same > version as the last source will cause DAK to reject the upload. That's a problem, then. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
On Mon Mar 30 17:20, Roger Leigh wrote: > With multiarch, it's a different story, but we aren't quite there yet. > Multiarch is definitely the right way to handle this and I think we should were possible be putting effort into that and not hacks. I still am not clear what the holdups are with multiarch. What is there that people like myself and the ia32-libs guys can do to get it working? I would really like to see it in squeeze if that's possible. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Peter Samuelson writes: > [Adeodato Simó] >> Mark Hymers has talked about providing a mechanism to ensure source >> packages stay on the pool when other stuff has been built from them (eg. >> kernel module packages). With this, ia32-libs could become a small >> source package containing scripts that would download the necessary >> binary packages at build time, and would encode in a header the employed >> versions; then, source for those versions would not be removed from the >> pool. > > I understand different binary packages from a single source package do > not have to share a single version string - so could ia32-libs be done > in such a way that each binary package gets a version number related to > the "real" source package it is built from? ia32-libs itself could > append a sort of 'micro-epoch' value that would only change when > substantive changes are made to how the binary packages are built. Currently ia32-libs source builds one ia32-libs.deb. Not split up per binary package it contains. > Thus when you binNMU ia32-libs in order to pick up a newer library > upload, all the libraries that have not changed will not get new > version numbers and nobody would need to upgrade them. But would this > situation (trying to upload a version that is already present) confuse > dak? I presume dak will just ignore that binary, yes? The problem isn't the really the user needing to downlod 40MB for an update. The problem I see is having to upload 600MB and mirror that. And yes, uploading a new source that builds a deb with the same version as the last source will cause DAK to reject the upload. For your idea to work the ia32-libs source has to be split. That would allow fine grained updates but still have the problem of source duplication and prebuild binaries. Ftpmaster didn't want that any more than ia32-libs now. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
On Mon, Mar 30, 2009 at 04:26:54PM +0200, Adeodato Simó wrote: > * Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]: > > Hello, [-mentors only Bcc'ed to drop it from the discussion] > > Executive summary: concerns about ia32-apt-get raised, lesser hack > proposed for comments. > > > before Lenny ftpmaster asked us (ia32-libs maintainers) to do > > something about the mess that is ia32-libs. Specifically that it is a > > HUGE source duplication and a security nightmare. Unfortunaetly there > > wasn't enough time before the release to get a new solution > > (ia32-apt-get) into a stable state. Now that Lenny is out the problem > > can be attacked again. The major remaining problems are how to > > transition from ia32-libs to ia32-apt-get and how packages can depend > > on 32bit libs then. (Which actualy hinge on the same problem.) > > Has there been any public discussions about ia32-apt-get, and consensus > that it is an acceptable solution? To be honest, I’m not sure at all it > is actually a better solution than the 500 MB source package. [...] > I realize quite a lot of effort has been put into writing this and to > make sure it works, but as said above, I’m unsure it’s an acceptable > solution to this problem. As an amd64 user, I’d be disgusted to see such > a hack forced down on my system, and disappointed in Debian for > sanctioning such solution. To be honest, I feel exactly the same way about it. I'm unsure why we need *any* 32-bit libraries or binaries on an amd64 system. If one needs to run 32-bit software, it is possible to debootstrap an i386 system and use it as a chroot. Using a tool such as schroot handles all of the kernel personality and chroot details, and even allows normal users to use it with access to all their files, etc. With a few one line scripts/shell aliases, it's completely transparent. It also has the advantage of being a complete i386 system rather than just a collection of libraries; you can keep it up to date using the usual tools, and even boot it if you desire. i.e. you get all the normal security support and updates. With multiarch, it's a different story, but we aren't quite there yet. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Samuel Thibault writes: > Goswin von Brederlow, le Mon 30 Mar 2009 14:33:32 +0200, a écrit : >> Ia32-apt-get provides wrappers for dpkg.deb and apt-get that allow >> installing deb packages from an i386 repository (or local file) >> directly. > > Mmm, couldn't there be any possible relation with the multiarch support > mentioned earlier on d-d? > > Samuel ia32-libs/ia32-apt-get is an ugly hack to support biarch while we wait for multiarch. multiarch is the clean solution for the problem. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Adeodato Simó writes: > * Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]: > > Hello, [-mentors only Bcc'ed to drop it from the discussion] > > Executive summary: concerns about ia32-apt-get raised, lesser hack > proposed for comments. > >> before Lenny ftpmaster asked us (ia32-libs maintainers) to do >> something about the mess that is ia32-libs. Specifically that it is a >> HUGE source duplication and a security nightmare. Unfortunaetly there >> wasn't enough time before the release to get a new solution >> (ia32-apt-get) into a stable state. Now that Lenny is out the problem >> can be attacked again. The major remaining problems are how to >> transition from ia32-libs to ia32-apt-get and how packages can depend >> on 32bit libs then. (Which actualy hinge on the same problem.) > > Has there been any public discussions about ia32-apt-get, and consensus > that it is an acceptable solution? To be honest, Iâm not sure at all it > is actually a better solution than the 500 MB source package. > > For the benefit of others, so that they can comment, Iâll mention how it > works. Mainly, ia32-apt-get dpkg-divertâs /usr/bin/apt-get and > /usr/bin/dpkg-deb. > > For apt-get, it intercepts the âupdateâ operation, calling apt-get.real > first in an alternative root for the host arch (/var/lib/apt/native), > then calling apt-get.real again for the foreign arch (/var/lib/apt/foreign), > and then doing gross sed'ing over those to morph them into acceptable > package lists for the host arch. Which are later available because the > postinst goes ahead and duplicates all entries in sources.list. > > For dpkg-deb, it intercepts â--controlâ and â--fsys-tarfileâ. The > latter > does all sorts of pretty things including moving files around (to > /usr/lib32, eg.), changing the Architecture field, and amending the > Depends field. > > I realize quite a lot of effort has been put into writing this and to > make sure it works, but as said above, Iâm unsure itâs an acceptable > solution to this problem. As an amd64 user, Iâd be disgusted to see such > a hack forced down on my system, and disappointed in Debian for > sanctioning such solution. The alternative solution is ia32-archive, which creates a local repository of converted packages on the users system. No wrappers needed and no ugly hacks but that comes at the cost of disk space and the need to configure what packages to convert (converting just everything would cost too much disk). The problem how to state the depends remains the same. >> The problem I see here is that ia32-libattr1, ia32-libx86-1, >> ia32-libpam0g, ... are not in main as far as DAK is concerned. They >> are not known at all in the Debian archive. As such I think [packages >> depending on ia32-lib*] could never transition from unstable to >> testing on [their] own. > > Actually they can, because britney can be told that some packages are > available even if they are not in the Packages lists. However, and given > my opinion above, I will refuse to do that unless thereâs clear consensus > among the active developers that this is an acceptable solution. Because > of that, opinions welcome. > > Iâd also be interested in hearing from ftpmaster their thoughts on the > matter. Maybe a less fugly hack can be devised if the need to address > the current ia32-libs mess is really strong. > > Mark Hymers has talked about providing a mechanism to ensure source > packages stay on the pool when other stuff has been built from them (eg. > kernel module packages). With this, ia32-libs could become a small > source package containing scripts that would download the necessary > binary packages at build time, and would encode in a header the employed > versions; then, source for those versions would not be removed from the > pool. Buildds don't have internet access in their build environment. ia32-libs may not download anything at build time. Plus rebuilding would give widely unreproducible results. As for avoiding the source duplication that would be nice. > And ia32-libs could be easily Bin-NMUed regularly, in order to pick up > the latest libraries from testing. I know downloading stuff in the build > process is not something we want to do, but we have packages with > special needs that do it by design (eg. the installer). > > Thoughts? Currently the size makes regular uploads too costly imho. And the security team is still not supporting ia32-libs. I even did prepare an security upload for etch last year that they only had to sponsor but never heard back from the team. > 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: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
[Adeodato Simó] > Mark Hymers has talked about providing a mechanism to ensure source > packages stay on the pool when other stuff has been built from them (eg. > kernel module packages). With this, ia32-libs could become a small > source package containing scripts that would download the necessary > binary packages at build time, and would encode in a header the employed > versions; then, source for those versions would not be removed from the > pool. I understand different binary packages from a single source package do not have to share a single version string - so could ia32-libs be done in such a way that each binary package gets a version number related to the "real" source package it is built from? ia32-libs itself could append a sort of 'micro-epoch' value that would only change when substantive changes are made to how the binary packages are built. Thus when you binNMU ia32-libs in order to pick up a newer library upload, all the libraries that have not changed will not get new version numbers and nobody would need to upgrade them. But would this situation (trying to upload a version that is already present) confuse dak? I presume dak will just ignore that binary, yes? -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
* Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]: Hello, [-mentors only Bcc'ed to drop it from the discussion] Executive summary: concerns about ia32-apt-get raised, lesser hack proposed for comments. > before Lenny ftpmaster asked us (ia32-libs maintainers) to do > something about the mess that is ia32-libs. Specifically that it is a > HUGE source duplication and a security nightmare. Unfortunaetly there > wasn't enough time before the release to get a new solution > (ia32-apt-get) into a stable state. Now that Lenny is out the problem > can be attacked again. The major remaining problems are how to > transition from ia32-libs to ia32-apt-get and how packages can depend > on 32bit libs then. (Which actualy hinge on the same problem.) Has there been any public discussions about ia32-apt-get, and consensus that it is an acceptable solution? To be honest, I’m not sure at all it is actually a better solution than the 500 MB source package. For the benefit of others, so that they can comment, I’ll mention how it works. Mainly, ia32-apt-get dpkg-divert’s /usr/bin/apt-get and /usr/bin/dpkg-deb. For apt-get, it intercepts the “update” operation, calling apt-get.real first in an alternative root for the host arch (/var/lib/apt/native), then calling apt-get.real again for the foreign arch (/var/lib/apt/foreign), and then doing gross sed'ing over those to morph them into acceptable package lists for the host arch. Which are later available because the postinst goes ahead and duplicates all entries in sources.list. For dpkg-deb, it intercepts “--control” and “--fsys-tarfile”. The latter does all sorts of pretty things including moving files around (to /usr/lib32, eg.), changing the Architecture field, and amending the Depends field. I realize quite a lot of effort has been put into writing this and to make sure it works, but as said above, I’m unsure it’s an acceptable solution to this problem. As an amd64 user, I’d be disgusted to see such a hack forced down on my system, and disappointed in Debian for sanctioning such solution. > The problem I see here is that ia32-libattr1, ia32-libx86-1, > ia32-libpam0g, ... are not in main as far as DAK is concerned. They > are not known at all in the Debian archive. As such I think [packages > depending on ia32-lib*] could never transition from unstable to > testing on [their] own. Actually they can, because britney can be told that some packages are available even if they are not in the Packages lists. However, and given my opinion above, I will refuse to do that unless there’s clear consensus among the active developers that this is an acceptable solution. Because of that, opinions welcome. I’d also be interested in hearing from ftpmaster their thoughts on the matter. Maybe a less fugly hack can be devised if the need to address the current ia32-libs mess is really strong. Mark Hymers has talked about providing a mechanism to ensure source packages stay on the pool when other stuff has been built from them (eg. kernel module packages). With this, ia32-libs could become a small source package containing scripts that would download the necessary binary packages at build time, and would encode in a header the employed versions; then, source for those versions would not be removed from the pool. And ia32-libs could be easily Bin-NMUed regularly, in order to pick up the latest libraries from testing. I know downloading stuff in the build process is not something we want to do, but we have packages with special needs that do it by design (eg. the installer). Thoughts? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Goswin von Brederlow, le Mon 30 Mar 2009 14:33:32 +0200, a écrit : > Ia32-apt-get provides wrappers for dpkg.deb and apt-get that allow > installing deb packages from an i386 repository (or local file) > directly. Mmm, couldn't there be any possible relation with the multiarch support mentioned earlier on d-d? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
