Re: ia32-libs{-tools}, multiarch, squeeze
Goswin von Brederlow goswin-...@web.de writes: And why should there be. The package it totally usable and functional as designed. Does it properly support aptitude / synaptic / etc yet? [The whole print a message on stdout telling the user he'd better do something else thing was dodgy beyond belief, and clearly is not acceptable for testing.] -Miles -- Brain, n. An apparatus with which we think we think. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Miles Bader mi...@gnu.org writes: Goswin von Brederlow goswin-...@web.de writes: And why should there be. The package it totally usable and functional as designed. Does it properly support aptitude / synaptic / etc yet? [The whole print a message on stdout telling the user he'd better do something else thing was dodgy beyond belief, and clearly is not acceptable for testing.] -Miles Sure the support isn't perfect yet. But it is useable. It is also purely a temporary inconvenience. The BTS has a patch for libapt that will allow better integration of ia32-apt-get (removes the need for any wrapper) and allows full functionality for all libapt using package managers. 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{-tools}, multiarch, squeeze
Micha Lenk mi...@lenk.info writes: Hi, Goswin von Brederlow wrote: Am Sonntag 05 Juli 2009 schrieb Goswin von Brederlow: The conversion system is an ugly hack. Sure. [...] [...] The package it totally usable and functional as designed. Don't you feel like contradicting yourself? Something can be a hack and still work. Imho it is the least ugly thing to ties 32bit support over till actual multiarch happens. 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{-tools}, multiarch, squeeze
Goswin von Brederlow goswin-...@web.de writes: Does it properly support aptitude / synaptic / etc yet? [The whole print a message on stdout telling the user he'd better do something else thing was dodgy beyond belief, and clearly is not acceptable for testing.] Sure the support isn't perfect yet. But it is useable. Not useable enough for testing though, that's all I'm saying. -Miles -- Run away! Run away! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Hi, Hans-J. Ullrich schrieb: Am Sonntag 05 Juli 2009 schrieb Goswin von Brederlow: The conversion system is an ugly hack. Sure. [...] Despite whatever the people say, I like the new package. And I like the idea behind it. And if it does not work at the beginning, who cares? It is unstable. To those who are mourning: Du you know the meaning of the word unstable? It means, there is no guarantee, things will work! It means, things must not be, as they were since many years. It means, things can crash. Except packages uploaded to unstable will automatically migrate to testing, the next stable release. So, if you already know in advance that the package is not suitable for any faraway release, you (the maintainer) should either file an RC bug against the 'unstable' version in order to keep the package out of testing or should have uploaded it to experimental. As of now I see no such RC bug... Regards Micha -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Micha Lenk mi...@lenk.info writes: Hi, Hans-J. Ullrich schrieb: Am Sonntag 05 Juli 2009 schrieb Goswin von Brederlow: The conversion system is an ugly hack. Sure. [...] Despite whatever the people say, I like the new package. And I like the idea behind it. And if it does not work at the beginning, who cares? It is unstable. To those who are mourning: Du you know the meaning of the word unstable? It means, there is no guarantee, things will work! It means, things must not be, as they were since many years. It means, things can crash. Except packages uploaded to unstable will automatically migrate to testing, the next stable release. So, if you already know in advance that the package is not suitable for any faraway release, you (the maintainer) should either file an RC bug against the 'unstable' version in order to keep the package out of testing or should have uploaded it to experimental. As of now I see no such RC bug... Regards Micha And why should there be. The package it totally usable and functional as designed. The only reason for it not to be in squeeze would be if multiarch support will be in squeeze. Which I doubt will actually happen. 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{-tools}, multiarch, squeeze
Hi, Goswin von Brederlow wrote: Am Sonntag 05 Juli 2009 schrieb Goswin von Brederlow: The conversion system is an ugly hack. Sure. [...] [...] The package it totally usable and functional as designed. Don't you feel like contradicting yourself? The only reason for it not to be in squeeze would be if multiarch support will be in squeeze. Which I doubt will actually happen. I think we are yet faraway from last decisions on what is going to be supported in squeeze and what not. So, IMHO it would be perfectly reasonable to keep the package out of squeeze for now. Once a package has migrated to testing it's bigger issue to get it back out there than getting it in in time for the next release... ... just my 2¢. Regards Micha -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
]] Yannick | But then, why do some bother with multiarch implementation? ;-) Because it solves the problem in a much more elegant way. | Correct me if I'm wrong, but doesn't multiarch do the same thing as ia32- | apt-get but at the distribution level? It accomplishes some of the same goals, which is not the same thing as doing the same thing. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Goswin von Brederlow wrote: Bernd Zeimetz be...@bzed.de writes: Goswin von Brederlow wrote: and it has numerous RC bugs. Lets see: http://packages.qa.debian.org/i/ia32-libs-tools.html RC bugs: 1 There were 6 bugs when I looked at the page before writing my mail, guess you've merged/downgraded/... the others.I should have added another one - breaking apt Most importantly fixed in an upload or assigned to the package that did the actual breaking. I got a number of non-bugs caused by libc6-i386 changing lib32 from link to directory too: Like lib32nss-mdns being uninstallable because libc6-i386 conflicts with it. completely while removing the ia32 packages is not nice. Remember, I asked you on irc? It leaves empty files somewhere in /var/lib/apt which breaks apt pretty much... -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
On Sun, Jul 05, 2009 at 10:41:10PM +0100, Roger Leigh wrote:
BTW, do you want a bug report about this against schroot?
Yes please! Since I have the memory of a goldfish, I can't forget
this way ;)
Done: #535943. I've tried to summarize the relevant points of this
design discussion; please add whatever I might have forgot.
I do that by hand for my chroots and I don't even have a wrapper
script, probably because my number of chroots (4) is still low. Having
a couple of wrappers schroot-{update,upgrade,...} would be more than
enough, if they by default run on *all* chroots registered within
schroot configuration. How does that sound? ...
You can already do this to a certain extent /without/ wrappers, for
example something like
schroot --all-chroots --user=root -- sh -c '[ -x $(which apt-get) ]
apt-get update apt-get -y upgrade'
But, we can't guarantee that all chroots are Debian chroots or that
automatic maintenance is required. I think that we should either
1) Have a file inside the chroot indicating that automated unattended
upgrades are OK, or
2) Have an option in the configuration file, such as
unattended-upgrades=true
which the initial chroot setup can enable, and updating tools can
query for (schroot itself will just ignore/preserve it).
In essence, it looks like my all above needs to be refined. What we
need is a way for the user to declare which chroots she wants to be
automatically handled by wrapper by default. That can be, for
instance, configured using keywords in schroot.conf entries(?). Also,
I guess, a way to invoke the wrapper on specific instances given on
the command line would be nice.
Notice that the assumption that all handled chroot should be Debian
is probably unsound. For instance, I can imagine an interest in having
Ubuntu, or other derivatives, chroots on my machine.
One other issue that casual users won't need to care about are the
different types of chroots schroot uses:
source - chroot - sessions (possibly cloned)
Right. That should be handled transparently by the wrapper. On chroots
having source equivalent, the upgrade should be done there. FWIW, this
answer an (unasked) question of mine, namely: can the wrapper be
simply developed on top of another wrapper which simply execute
commands in a given chroot? The answer is no, cause we know upgrades
should be done in source chroots.
If anyone has experience of using SWIG to wrap a C++ interface for
use in Perl, please get in touch. A Perl binding to schroot would
be absolutely awesome, but I lack the expertise with SWIG to know
how to get started.
Sorry, not here :-/
That would be the ideal, yes. There is a slight restriction that
chroot names can't be duplicated, so if you drop a chroot in there
that has the same name as an existing one, schroot will moan until
you rename one. But that's always been a deliberate design feature;
we would just need to ensure the packages don't use the same names.
Well, while I guess that most of us already have chroots called sid,
lenny, and so on, we can go for sid-instance or something such to
distinguish legacy (i.e., packaged) chroots from the othere.
Thanks for this intriguing discussion,
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: ia32-libs{-tools}, multiarch, squeeze
Bernd Zeimetz be...@bzed.de writes: Goswin von Brederlow wrote: Bernd Zeimetz be...@bzed.de writes: Goswin von Brederlow wrote: and it has numerous RC bugs. Lets see: http://packages.qa.debian.org/i/ia32-libs-tools.html RC bugs: 1 There were 6 bugs when I looked at the page before writing my mail, guess you've merged/downgraded/... the others.I should have added another one - breaking apt Most importantly fixed in an upload or assigned to the package that did the actual breaking. I got a number of non-bugs caused by libc6-i386 changing lib32 from link to directory too: Like lib32nss-mdns being uninstallable because libc6-i386 conflicts with it. completely while removing the ia32 packages is not nice. Remember, I asked you on irc? It leaves empty files somewhere in /var/lib/apt which breaks apt pretty much... Fixed in version 19: * Remove empty Packages files on remove so update fetches fresh ones. So another fixed in an upload one. :)) 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{-tools}, multiarch, squeeze
On Sat, Jul 04, 2009 at 11:30:12PM +0200, Goswin von Brederlow wrote: Yannick yannick.roeh...@free.fr writes: Goswin von Brederlow wrote: And hey, the good reason was diverting the package management tools is unacceptable. But, no, we have to do insults instead of arguing. Alas, despite the diversion of the package management tools, I find ia32- apt-get pretty useful. For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript engine). With ia32-apt-get, I could install the 32bit version of my GTK theme engine so that Firefox can look good. Is there a design problem in converting 32bits libraries to ia32-* packages or the sole problem is the diversion of apt-get and co? There where 3 minor bug reports about an ia32-* package not working right. Out of an estimate of 160-200 packages people use. I think that is pretty good. All 3 bugs where fix in a subsequent upload and currently there are no reported missconversions. On the other hand ~45 bugs about missconversion or missing packages in the old ia32-libs where closed (and will have to be reopened now). So I don't believe there is a design problem there. That part works just fine. But the diversions had people totaly in outrage. So much so that I believe they didn't even look past that at all. You absolutely don't get it do you ? Your conversion system is an ugly hack, something completely horrible, that is meant to break in horrible ways, has no forward upgrate path to a multiarch work, and so on. If you really mean to provide something like ia32-apt-get, what you ought to do is to: - help the user create and maintain a proper 32bits chroot; - let ia32-apt-get or whatever it's called be a forward to running apt-get inside that chroot; - find a way to let the user run commands from that chroot seamlessly. That would be totally acceptable, and probably an improvement over the current situation. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Re: ia32-libs{-tools}, multiarch, squeeze
Pierre Habouzit madco...@madism.org writes: On Sat, Jul 04, 2009 at 11:30:12PM +0200, Goswin von Brederlow wrote: Yannick yannick.roeh...@free.fr writes: Goswin von Brederlow wrote: And hey, the good reason was diverting the package management tools is unacceptable. But, no, we have to do insults instead of arguing. Alas, despite the diversion of the package management tools, I find ia32- apt-get pretty useful. For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript engine). With ia32-apt-get, I could install the 32bit version of my GTK theme engine so that Firefox can look good. Is there a design problem in converting 32bits libraries to ia32-* packages or the sole problem is the diversion of apt-get and co? There where 3 minor bug reports about an ia32-* package not working right. Out of an estimate of 160-200 packages people use. I think that is pretty good. All 3 bugs where fix in a subsequent upload and currently there are no reported missconversions. On the other hand ~45 bugs about missconversion or missing packages in the old ia32-libs where closed (and will have to be reopened now). So I don't believe there is a design problem there. That part works just fine. But the diversions had people totaly in outrage. So much so that I believe they didn't even look past that at all. You absolutely don't get it do you ? Your conversion system is an ugly hack, something completely horrible, that is meant to break in horrible ways, has no forward upgrate path to a multiarch work, and so on. The conversion system is an ugly hack. Sure. But it is the same ugly hack 32bit support has always done, for over 5 years. The only change is when the conversion is done, i.e. moved from the buildd to the users system. By moving it there only those things the user needs/wants need converting and all the user needs/wants can be converted. That is the big advantage of ia32-apt-get over ia32-libs. If you find the conversion unacceptable then the only option for you is to request 32bit support on amd64/ia64 is removed till multiarch. The upgrade path to multiarch is for the multiarch i386 deb to Conflicts/Replaces: package that contains the same files. Which means ia32-libs or ia32-libs-gtk for the old system or ia32-package for the ia32-apt-get one. And again with ia32-apt-get there is a huge advantage. As packages convert to multiarch they can be droped in ia32-apt-get on a case by case basis and replaced by the multiarch one. Meaning users don't have to wait for and update 200 packages in a single step. If you really mean to provide something like ia32-apt-get, what you ought to do is to: - help the user create and maintain a proper 32bits chroot; Way to complex and fragile with the millions of possible configurations of users systems. - let ia32-apt-get or whatever it's called be a forward to running apt-get inside that chroot; - find a way to let the user run commands from that chroot seamlessly. Impossible to make that work for everyone/everything. Any solution will be a special case solution and only support some configurations. That would be totally acceptable, and probably an improvement over the current situation. 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{-tools}, multiarch, squeeze
Am Sonntag 05 Juli 2009 schrieb Goswin von Brederlow: The conversion system is an ugly hack. Sure. But it is the same ugly hack 32bit support has always done, for over 5 years. The only change is when the conversion is done, i.e. moved from the buildd to the users system. By moving it there only those things the user needs/wants need converting and all the user needs/wants can be converted. That is the big advantage of ia32-apt-get over ia32-libs. If you find the conversion unacceptable then the only option for you is to request 32bit support on amd64/ia64 is removed till multiarch. The upgrade path to multiarch is for the multiarch i386 deb to Conflicts/Replaces: package that contains the same files. Which means ia32-libs or ia32-libs-gtk for the old system or ia32-package for the ia32-apt-get one. And again with ia32-apt-get there is a huge advantage. As packages convert to multiarch they can be droped in ia32-apt-get on a case by case basis and replaced by the multiarch one. Meaning users don't have to wait for and update 200 packages in a single step. Way to complex and fragile with the millions of possible configurations of users systems. - let ia32-apt-get or whatever it's called be a forward to running apt-get inside that chroot; - find a way to let the user run commands from that chroot seamlessly. Impossible to make that work for everyone/everything. Any solution will be a special case solution and only support some configurations. That would be totally acceptable, and probably an improvement over the current situation. MfG Goswin Despite whatever the people say, I like the new package. And I like the idea behind it. And if it does not work at the beginning, who cares? It is unstable. To those who are mourning: Du you know the meaning of the word unstable? It means, there is no guarantee, things will work! It means, things must not be, as they were since many years. It means, things can crash. It means, people are welcome, to walk new ways. It is means, HERE is the development and innovation. When you want a ready out-of-the-box system, use Windows, or better Apple MacOS or just stable. It is linux, where everybody gets the chance, to change things to their personal needs. If you do not like it this way, do never use KDE4, as at the moment, it has got also things, which are not running at the moment. So. let the people test, invent, make errors, make crashs, make everything - but stop grouching! So, that had to be said! But now to another thing: Is there a way, to get rid off dependencies in third-party applications to old ia32-libs and old ia32-libs-gtk? Apt wants to deinstall them, when I want to install ia32-apt-get (and of course the related third party applications) Cheers 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{-tools}, multiarch, squeeze
]] Yannick | For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 | Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript | engine). With ia32-apt-get, I could install the 32bit version of my | GTK theme engine so that Firefox can look good. You could just use a chroot. It's not that hard. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
On Sun, Jul 05, 2009 at 01:26:23PM +0200, Tollef Fog Heen wrote:
]] Yannick
| For instance, I wanted to test Firefox 3.5 in 32bits on my amd64
| Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript
| engine). With ia32-apt-get, I could install the 32bit version of my
| GTK theme engine so that Firefox can look good.
You could just use a chroot. It's not that hard.
Oh come on, this is really a non-argument. Here we are trying to build
a system that can be used by random users, not developers (like
probably all of the people reading this thread) with half dozen
entries in their schroot.conf.
Not arguing about the merits of the specific implementation of
ia32-apt-get, the approach had the advantage that a, say, synaptic
user can use it. A chroot does not enjoy that good property.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: ia32-libs{-tools}, multiarch, squeeze
]] Stefano Zacchiroli | On Sun, Jul 05, 2009 at 01:26:23PM +0200, Tollef Fog Heen wrote: | ]] Yannick | | | For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 | | Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript | | engine). With ia32-apt-get, I could install the 32bit version of my | | GTK theme engine so that Firefox can look good. | | You could just use a chroot. It's not that hard. | | Oh come on, this is really a non-argument. Here we are trying to build | a system that can be used by random users, not developers (like | probably all of the people reading this thread) with half dozen | entries in their schroot.conf. No, I don't think so. Coming up with random maybe-somewhat-working solutions to cross-installing packages will only take a proper solution take more time to get implemented, since people will be less interested in fixing the problem once their pet problem goes away. | Not arguing about the merits of the specific implementation of | ia32-apt-get, the approach had the advantage that a, say, synaptic | user can use it. A chroot does not enjoy that good property. unless it broke apt completely, requiring more hand-holding than constructing a chroot, you mean? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
On Sun, Jul 05, 2009 at 04:37:50PM +0200, Tollef Fog Heen wrote:
No, I don't think so. Coming up with random maybe-somewhat-working
solutions to cross-installing packages will only take a proper solution
take more time to get implemented, since people will be less interested
in fixing the problem once their pet problem goes away.
| Not arguing about the merits of the specific implementation of
| ia32-apt-get, the approach had the advantage that a, say, synaptic
| user can use it. A chroot does not enjoy that good property.
unless it broke apt completely, requiring more hand-holding than
constructing a chroot, you mean?
You are stretching my arguments. I did not touch the (de)merits of
ia32-apt-get with my post, on purpose, and I've even said that
explicitly in my text.
I've just pointed out that the use a chroot, is not that hard
argument is simply bogus since not all our users are power users. We
are trying to build the universal operating system here.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: ia32-libs{-tools}, multiarch, squeeze
On Sun, Jul 05, 2009 at 03:07:58PM +0200, Stefano Zacchiroli wrote: On Sun, Jul 05, 2009 at 01:26:23PM +0200, Tollef Fog Heen wrote: ]] Yannick | For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 | Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript | engine). With ia32-apt-get, I could install the 32bit version of my | GTK theme engine so that Firefox can look good. You could just use a chroot. It's not that hard. Oh come on, this is really a non-argument. Here we are trying to build a system that can be used by random users, not developers (like probably all of the people reading this thread) with half dozen entries in their schroot.conf. The fact that schroot was primarily written for developers does not make it any less useful for ordinary users. The current version has features such as /etc/schroot/chroot.d which are intended to allow other programs or packages to drop chroot definitions in there. This was done with the intent that someone could write a simple script to create a chroot, drop an automatically generated configuration in there, and it will Just Work™. The existing setup will by default set up /home, /tmp etc. as on the host system, so for most users, it will appear completely transparent. If you look at the sbuild-createchroot script in sbuild, which is a wrapper around debootstrap to set up a buildd chroot, you'll see that it does just this. While I don't personally have the time or inclination to write a user-centric script, such a script could very easily be written to allow such use. TBH, users can just use the existing script, with perhaps some additions to install what they need. As I see it, there are two major hurdles: 1) Initial creation of the chroot. As above, I think a simple script to integrate with the existing tools would work just fine here. 2) An easy way to run programs inside the chroot. This depends upon exactly what you want to do. Wrapper scripts or shell aliases do a good job for existing users; automatically generated desktop menu files for specific applications would also work. While I agree that chroots do appear more technical and fiddly to set up, the reality is that we now have the means to set them up in a reliable and automated fashion, and this will give the user a more robust environment than a monolithic library package set from a security POV, as well as giving them access to the /entire/ archive rather than a restricted subset, making it rather more useful. While multiarch should solve this problem, chroots offer rather more functionality and reliability at the present time, with a (rather small) hurdle to set up initially. 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: ia32-libs{-tools}, multiarch, squeeze
Tollef Fog Heen wrote: ]] Yannick | For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 | Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript | engine). With ia32-apt-get, I could install the 32bit version of my | GTK theme engine so that Firefox can look good. You could just use a chroot. It's not that hard. Hi Tollef, Of course I could use a chroot (even though I didn't know that schroot could permit me to use my home folder inside a chroot). But then, why do some bother with multiarch implementation? ;-) Correct me if I'm wrong, but doesn't multiarch do the same thing as ia32- apt-get but at the distribution level? Sincerely, 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{-tools}, multiarch, squeeze
On Sun, Jul 05, 2009 at 04:17:15PM +0100, Roger Leigh wrote:
The fact that schroot was primarily written for developers does not
make it any less useful for ordinary users. The current version has
features such as /etc/schroot/chroot.d which are intended to allow
other programs or packages to drop chroot definitions in there.
This was done with the intent that someone could write a simple
script to create a chroot, drop an automatically generated
configuration in there, and it will Just Work™. The existing setup
will by default set up /home, /tmp etc. as on the host system, so
for most users, it will appear completely transparent.
Thanks for biting: this is an interesting part of the discussion, with
chances to improve user experiences not only in this particular case,
but also in testing more safely packages coming from other suites or
third party repositories.
As I see it, there are two major hurdles:
1) Initial creation of the chroot. As above, I think a simple
script to integrate with the existing tools would work just fine
here.
Sure, perhaps triggered when installing schroot via debconf or, even
better to not bother developer-type of users, when installing a
facade package such as schroot-lenny or something such.
2) An easy way to run programs inside the chroot. This depends upon
exactly what you want to do. Wrapper scripts or shell aliases do
a good job for existing users; automatically generated desktop
menu files for specific applications would also work.
ACK.
But I see a third one.
3) How to maintain the chroot. With the chroots that I use (I've 4 of
them: three for cowbuilding in different suites, and a 32 bit one)
they always end up being out of date. I developed the habit of
updating them just before building on top of them. For users we
really need a way to update them in a semi-automated way that takes
care of security upgrades (at least). Maybe unattended-upgrades
with a specific configuration can be the way to go?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: ia32-libs{-tools}, multiarch, squeeze
On Sun, Jul 05, 2009 at 07:00:38PM +0200, Stefano Zacchiroli wrote: As I see it, there are two major hurdles: 1) Initial creation of the chroot. As above, I think a simple script to integrate with the existing tools would work just fine here. Sure, perhaps triggered when installing schroot via debconf or, even better to not bother developer-type of users, when installing a facade package such as schroot-lenny or something such. Exactly. Such a package can automatically debootstrap and set up a suitable chroot environment without any hand-holding by the user. It can even borrow all the apt settings such as sources.list from the host. I do like this idea. We could provide a number of packages, both named debian releases, perhaps also Providing stable/testing/unstable aliases, and maybe a common package for the scripts themselves. This should probably be packaged separately from schroot itself, since it might require updating independently of the schroot release cycle to work with Debian releases. Thinking about it, such as setup is useful even for non-user applications such as for buildd use, at least for the initial setup; automated upgrades are less of an issue here, since the tools already take some care of it. 2) An easy way to run programs inside the chroot. This depends upon exactly what you want to do. Wrapper scripts or shell aliases do a good job for existing users; automatically generated desktop menu files for specific applications would also work. ACK. But I see a third one. 3) How to maintain the chroot. With the chroots that I use (I've 4 of them: three for cowbuilding in different suites, and a 32 bit one) they always end up being out of date. I developed the habit of updating them just before building on top of them. For users we really need a way to update them in a semi-automated way that takes care of security upgrades (at least). Maybe unattended-upgrades with a specific configuration can be the way to go? This is a very valid point. Since it's an entire system within a system, it does need perioding updating with apt/aptitude. For sbuild use, we have the general tools sbuild-update/sbuild-upgrade etc. which are just thin wrappers around schroot -c $chroot -u root -- apt-get update etc. But they still need running by hand or via a cron job (or for sbuild use, they can be triggered to run before a build). I don't have a good answer for how this should be handled for normal users. Currently they would need to do this by hand or via a wrapper to make it simpler. Something along the lines of unattended-upgrades would be nice, driven by a cron job. This could be provided directly inside the chroot containing package the user would install. This is one area where multiarch will vastly improve the user experience, since it's all done on a single system. At least for the simple 32/64-bit system case; you'll still need virtualisation for multiple distributions, which it won't cater for. 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: ia32-libs{-tools}, multiarch, squeeze
On 2009-07-05, Stefano Zacchiroli z...@debian.org wrote: 3) How to maintain the chroot. With the chroots that I use (I've 4 of them: three for cowbuilding in different suites, and a 32 bit one) they always end up being out of date. I developed the habit of updating them just before building on top of them. For users we really need a way to update them in a semi-automated way that takes care of security upgrades (at least). Maybe unattended-upgrades with a specific configuration can be the way to go? OTOH the main system is not automatically upgraded neither. Maybe a post- upgrade hook or similar would be appropriate in this case? How could one help to get multiarch happen by the way? Or does it currently depend on Guillem coding up the foundation in dpkg anyway? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Philipp Kern tr...@philkern.de (05/07/2009): How could one help to get multiarch happen by the way? Or does it currently depend on Guillem coding up the foundation in dpkg anyway? Maybe we could have a bug against general about multiarch support, blocked by bugs against each and every component that needs tweaking. This way, one should be able to follow the progress in each area? Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
On Sun, Jul 05, 2009 at 05:35:13PM +, Philipp Kern wrote:
On 2009-07-05, Stefano Zacchiroli z...@debian.org wrote:
3) How to maintain the chroot. With the chroots that I use (I've 4 of
snip
OTOH the main system is not automatically upgraded neither. Maybe a post-
upgrade hook or similar would be appropriate in this case?
Sure. My point was more about the _additional_ need of upgrading
sub-systems, need of which users might not be aware, while they are
expected to be aware of how to upgrade the main system. More
generally, the issue is how to integrate the management of sub-systems
within the management (and related tools) we already have to manage
the main systems.
That, unsurprisingly, is the same problem faced by ia32-libs and, by
popular judgement, badly handled. More interestingly, it is in some
way also the same problem that will be faced in maintaining images for
virtual machines ... (as long as the virtual machines are still
Debian).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: ia32-libs{-tools}, multiarch, squeeze
On Sun, Jul 05, 2009 at 06:29:30PM +0100, Roger Leigh wrote:
Exactly. Such a package can automatically debootstrap and set up a
suitable chroot environment without any hand-holding by the user.
It can even borrow all the apt settings such as sources.list from
the host.
Yep, but not directly, because you'll need to mangle distro settings
and stuff like that. Also, if you initialize APT settings the first
time you create the chroots from the base system, people might then
expect them to be kept synchronized in the future. What about copying
them into the chroot by default as, IIUC, schroot can do for other
files?
I do like this idea. We could provide a number of packages, both
named debian releases, perhaps also Providing
stable/testing/unstable aliases, and maybe a common package for the
scripts themselves.
It starts to get exciting :)
BTW, do you want a bug report about this against schroot?
Thinking about it, such as setup is useful even for non-user
applications such as for buildd use, at least for the initial setup;
automated upgrades are less of an issue here, since the tools
already take some care of it.
I cannot agree more. I use a plethora of chroots for package
buildings, but I know various DDs which are not (yet) using stuff like
cowbuilder due to the ignorance about schroot and similar helper
tools. Having the packages we are discussing easy to use out of the
box can terribly help in spreading good package building culture.
3) How to maintain the chroot. With the chroots that I use (I've 4 of
snip
This is a very valid point. Since it's an entire system within a
system, it does need perioding updating with apt/aptitude. For
sbuild use, we have the general tools sbuild-update/sbuild-upgrade
etc. which are just thin wrappers around
schroot -c $chroot -u root -- apt-get update etc. But they still
need running by hand or via a cron job (or for sbuild use, they can
be triggered to run before a build).
I don't have a good answer for how this should be handled for normal
users. Currently they would need to do this by hand or via a wrapper
to make it simpler. Something along the lines of unattended-upgrades
would be nice, driven by a cron job. This could be provided directly
inside the chroot containing package the user would install.
I do that by hand for my chroots and I don't even have a wrapper
script, probably because my number of chroots (4) is still low. Having
a couple of wrappers schroot-{update,upgrade,...} would be more than
enough, if they by default run on *all* chroots registered within
schroot configuration. How does that sound? ...
I notice just now that schroot already supports
/etc/schroot/chroot.d/, so the additional chroot instance packages can
just drop entries there and have the wrapper scripts work on them out
of the box.
Pretty cool stuff.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: ia32-libs{-tools}, multiarch, squeeze
On Sun, Jul 05, 2009 at 12:20:08PM +0200, Goswin von Brederlow wrote: The upgrade path to multiarch is for the multiarch i386 deb to Conflicts/Replaces: package that contains the same files. Which means ia32-libs or ia32-libs-gtk for the old system or ia32-package for the ia32-apt-get one. If this means ia32-apt-get is installing files to the multiarch paths, then this is a problem. You're making more work for the implementers of multiarch by requiring them to take into account this ia32-apt-get kludge. -- 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{-tools}, multiarch, squeeze
Yannick yannick.roeh...@free.fr writes: Correct me if I'm wrong, but doesn't multiarch do the same thing as ia32- apt-get but at the distribution level? My impression is that it's not necessarily the abstract idea of ia32-apt-get that's so wrong, but rather the apparently clumsy way it was implemented. I, at least, was completely taken by surprise when everything started breaking, and get the feeling that one of the big problems is that all of this was done without adequate communication/consultation beforehand. [Ok, maybe I just missed the pre-breakage discussion/flames (the post-breakage discussion/flames are all too obvious :), but this seems much less carefully planned than most debian transitions...] -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Roger Leigh rle...@codelibre.net writes: On Sun, Jul 05, 2009 at 03:07:58PM +0200, Stefano Zacchiroli wrote: On Sun, Jul 05, 2009 at 01:26:23PM +0200, Tollef Fog Heen wrote: ]] Yannick | For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 | Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript | engine). With ia32-apt-get, I could install the 32bit version of my | GTK theme engine so that Firefox can look good. You could just use a chroot. It's not that hard. Oh come on, this is really a non-argument. Here we are trying to build a system that can be used by random users, not developers (like probably all of the people reading this thread) with half dozen entries in their schroot.conf. The fact that schroot was primarily written for developers does not make it any less useful for ordinary users. The current version has features such as /etc/schroot/chroot.d which are intended to allow other programs or packages to drop chroot definitions in there. This was done with the intent that someone could write a simple script to create a chroot, drop an automatically generated configuration in there, and it will Just Workâ¢. The existing setup will by default set up /home, /tmp etc. as on the host system, so for most users, it will appear completely transparent. If you look at the sbuild-createchroot script in sbuild, which is a wrapper around debootstrap to set up a buildd chroot, you'll see that it does just this. While I don't personally have the time or inclination to write a user-centric script, such a script could very easily be written to allow such use. TBH, users can just use the existing script, with perhaps some additions to install what they need. As I see it, there are two major hurdles: 1) Initial creation of the chroot. As above, I think a simple script to integrate with the existing tools would work just fine here. Which must handle all possible user configurations for mail, sound, printing, 2) An easy way to run programs inside the chroot. This depends upon exactly what you want to do. Wrapper scripts or shell aliases do a good job for existing users; automatically generated desktop menu files for specific applications would also work. Which then can't generaly send mail, play sound nicely (mix with the non-chroot sound), print documents, ... And most unsovably: You can not start 64bit programs from inside the 32bit chroot again, have them start 32bit, 64, 32, 64, 32, ... How many levels bind mounts do you want to do? While I agree that chroots do appear more technical and fiddly to set up, the reality is that we now have the means to set them up in a reliable and automated fashion, and this will give the user a more robust environment than a monolithic library package set from a security POV, as well as giving them access to the /entire/ archive rather than a restricted subset, making it rather more useful. While multiarch should solve this problem, chroots offer rather more functionality and reliability at the present time, with a (rather small) hurdle to set up initially. Not in a way that is suitable for general desktop applications. And hey, here is this existing way of doing all this so that none of these problems arise: ia32-apt-get. It also is not monolithic, nor a security problem and also gives access to the full archive. Initially it was too much of it even. Regards, Roger 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{-tools}, multiarch, squeeze
On Sun, Jul 05, 2009 at 09:06:13PM +0200, Stefano Zacchiroli wrote:
On Sun, Jul 05, 2009 at 06:29:30PM +0100, Roger Leigh wrote:
Exactly. Such a package can automatically debootstrap and set up a
suitable chroot environment without any hand-holding by the user.
It can even borrow all the apt settings such as sources.list from
the host.
Yep, but not directly, because you'll need to mangle distro settings
and stuff like that. Also, if you initialize APT settings the first
time you create the chroots from the base system, people might then
expect them to be kept synchronized in the future. What about copying
them into the chroot by default as, IIUC, schroot can do for other
files?
That's certainly a possibility. We can extend it to do whatever we
like during the setup stage, so a dedicated script to copy over the
current APT settings is easy. However, this could also break quite
easily if the user adds lots of custom stuff like local files that
aren't available in the chroot.
If the geo-ip mirror stuff is now working reliably, this means we
always have a good default to use which the user can then customise
if required. Or if debconf has the chosen country mirror stored from
installation, we just default to using that.
I do like this idea. We could provide a number of packages, both
named debian releases, perhaps also Providing
stable/testing/unstable aliases, and maybe a common package for the
scripts themselves.
It starts to get exciting :)
BTW, do you want a bug report about this against schroot?
Yes please! Since I have the memory of a goldfish, I can't forget
this way ;)
Thinking about it, such as setup is useful even for non-user
applications such as for buildd use, at least for the initial setup;
automated upgrades are less of an issue here, since the tools
already take some care of it.
I cannot agree more. I use a plethora of chroots for package
buildings, but I know various DDs which are not (yet) using stuff like
cowbuilder due to the ignorance about schroot and similar helper
tools. Having the packages we are discussing easy to use out of the
box can terribly help in spreading good package building culture.
Absolutely. This is one area I've worked on quite a bit with tools
like sbuild-createchroot. While this automates what was once quite
arcane and fiddly, it still doesn't tackle the ongoing maintenance
(see below).
3) How to maintain the chroot. With the chroots that I use (I've 4 of
snip
I don't have a good answer for how this should be handled for normal
users. Currently they would need to do this by hand or via a wrapper
to make it simpler. Something along the lines of unattended-upgrades
would be nice, driven by a cron job. This could be provided directly
inside the chroot containing package the user would install.
I do that by hand for my chroots and I don't even have a wrapper
script, probably because my number of chroots (4) is still low. Having
a couple of wrappers schroot-{update,upgrade,...} would be more than
enough, if they by default run on *all* chroots registered within
schroot configuration. How does that sound? ...
You can already do this to a certain extent /without/ wrappers, for
example something like
schroot --all-chroots --user=root -- sh -c '[ -x $(which apt-get) ]
apt-get update apt-get -y upgrade'
But, we can't guarantee that all chroots are Debian chroots or that
automatic maintenance is required. I think that we should either
1) Have a file inside the chroot indicating that automated unattended
upgrades are OK, or
2) Have an option in the configuration file, such as
unattended-upgrades=true
which the initial chroot setup can enable, and updating tools can
query for (schroot itself will just ignore/preserve it).
One other issue that casual users won't need to care about are the
different types of chroots schroot uses:
source - chroot - sessions (possibly cloned)
Some chroots can be cloned (LVM snapshots and coming very soon
[merged over the weekend] filesystem unions), and these have a
corresponding source chroot (the original filesystem) to allow
for updating, since updating the clone would need doing repeatedly
for each new clone. The interface doesn't yet allow for running an
update command in all source chroots, but once that's added it will
allow for easy bulk management of all chroots.
The sbuild update and creation code is actually all in a Perl module
(libsbuild-perl), and we can make this even more generic for use
outside sbuild. However, the reason most of this code exists is
because it's not currently possible to call the schroot C++ library
interface directly from Perl. If anyone has experience of using SWIG
to wrap a C++ interface for use in Perl, please get in touch. A
Perl binding to schroot would be absolutely awesome, but I lack the
expertise with SWIG to know how to get started.
I notice just now that schroot already supports
Re: ia32-libs{-tools}, multiarch, squeeze
Tollef Fog Heen tfh...@err.no writes: ]] Stefano Zacchiroli | On Sun, Jul 05, 2009 at 01:26:23PM +0200, Tollef Fog Heen wrote: | ]] Yannick | | | For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 | | Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript | | engine). With ia32-apt-get, I could install the 32bit version of my | | GTK theme engine so that Firefox can look good. | | You could just use a chroot. It's not that hard. | | Oh come on, this is really a non-argument. Here we are trying to build | a system that can be used by random users, not developers (like | probably all of the people reading this thread) with half dozen | entries in their schroot.conf. No, I don't think so. Coming up with random maybe-somewhat-working solutions to cross-installing packages will only take a proper solution take more time to get implemented, since people will be less interested in fixing the problem once their pet problem goes away. More than oh say 5 years? Sorry, but that train has long gone. Maybe ia32-libs did that. But it already did it. | Not arguing about the merits of the specific implementation of | ia32-apt-get, the approach had the advantage that a, say, synaptic | user can use it. A chroot does not enjoy that good property. unless it broke apt completely, requiring more hand-holding than constructing a chroot, you mean? Which was a bug, which for most people it didn't, which needed a one time intervention to install and configure it, which it can't even do anymore since it stoped diverting apt. The ia32-apt-get design actualy is so as to remove all the hand-holding ia32-libs needs. That is the part that is plain unmaintainable in ia32-libs. And yes, multiarch would be better but it is not here NOW and people want 32bit 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: ia32-libs{-tools}, multiarch, squeeze
On Sun, Jul 05, 2009 at 11:36:31PM +0200, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: As I see it, there are two major hurdles: 1) Initial creation of the chroot. As above, I think a simple script to integrate with the existing tools would work just fine here. Which must handle all possible user configurations for mail, sound, printing, I'm not sure I agree here. All possible configurations is a rather impossible goal for any system. The creator of any package would need to decide what to support by default. It can use the d-i tasks just like a normal installation would, but the user will ultimately have the power to configure it as they see fit. Although I use amd64, I have yet to want to install any 32bit software, so I'm not entirely sure what the use case is for it. If we're talking about specific programs such as proprietary binary- only software and browser plugins etc., then we really only need the specific software and its dependencies in there. I really don't see the need for an entire functional desktop environment inside the chroot, for example. Some further clarification is needed here. 2) An easy way to run programs inside the chroot. This depends upon exactly what you want to do. Wrapper scripts or shell aliases do a good job for existing users; automatically generated desktop menu files for specific applications would also work. Which then can't generaly send mail, play sound nicely (mix with the non-chroot sound), print documents, ... These tasks just require the necessary client libraries and/or programs to talk to the server. In the case of the sound, the device nodes are shared with the host system, as is SYSV and POSIX SHM. For server AF_LOCAL sockets, we can bind mount the sockets in there as well. And most unsovably: You can not start 64bit programs from inside the 32bit chroot again, have them start 32bit, 64, 32, 64, 32, ... How many levels bind mounts do you want to do? Well, from a kernel POV, you can certainly use personality(2) to switch the execdomain back to PER_LINUX from PER_LINUX32. You are correct that starting 64bit programs on the host from inside the chroot is not possible. The isolation of the filesystem from the host is, of course, the defining feature of a chroot environment. If we are running specific programs inside only, is this a problem in practice? It's certainly possible to install schroot inside the chroot and then chroot back into a virtual host system, but I do admit that's rather gross! While I agree that chroots do appear more technical and fiddly to set up, the reality is that we now have the means to set them up in a reliable and automated fashion, and this will give the user a more robust environment than a monolithic library package set from a security POV, as well as giving them access to the /entire/ archive rather than a restricted subset, making it rather more useful. While multiarch should solve this problem, chroots offer rather more functionality and reliability at the present time, with a (rather small) hurdle to set up initially. Not in a way that is suitable for general desktop applications. And hey, here is this existing way of doing all this so that none of these problems arise: ia32-apt-get. It also is not monolithic, nor a security problem and also gives access to the full archive. Initially it was too much of it even. I'd rather see a working multiarch implementation in the long term. I agree that the chroot setup is not as ideal as multiarch, but there are quite a lot of people using schroot in practice for this purpose. I would be interested to know exactly why it's not suitable for general desktop applications, and exactly what use cases you are planning for which lead to this being the case. 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: ia32-libs{-tools}, multiarch, squeeze
Steve Langasek vor...@debian.org writes: On Sun, Jul 05, 2009 at 12:20:08PM +0200, Goswin von Brederlow wrote: The upgrade path to multiarch is for the multiarch i386 deb to Conflicts/Replaces: package that contains the same files. Which means ia32-libs or ia32-libs-gtk for the old system or ia32-package for the ia32-apt-get one. If this means ia32-apt-get is installing files to the multiarch paths, then this is a problem. You're making more work for the implementers of multiarch by requiring them to take into account this ia32-apt-get kludge. There are a lot more things in those packages than *.so files. That is what the Replaces is needed for. The Conflicts on the other hand is needed so only one version of the library is installed on the system. Otherwise you will get the wrong version and things randomly break as Depends/Breaks/Conflicts won't catch right. This already holds for the old ia32-libs and ia32-libs-gtk and has nothing to do with ia32-apt-get or installing to multiarch paths. 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{-tools}, multiarch, squeeze
Roger Leigh rle...@codelibre.net writes: Although I use amd64, I have yet to want to install any 32bit software, so I'm not entirely sure what the use case is for it. While I agree in general, I do occasionally want a more fully functional 32-bit system infrastructure. Typically this is when I need to compile a program which is buggy, and has 32-bit assumptions in it, or runs faster in 32-bit mode, or whatever. When all the libraries the program needs are available in ia32-libs, then gcc -m32 works great, but when they _aren't_, it can get miserable pretty quickly. So I love the _idea_ of a seamless automatic system for installing arbitrary 32-bit libraries on amd64. The current ia32-apt-get thing, seems pretty kludgey and fragile though... [I've reverted my systems to the old versions for the time being and have a lot of packages on hold... hopefully after a while either things will be a bit more solid or these changes will have been backed out.] -Miles -- Barometer, n. An ingenious instrument which indicates what kind of weather we are having. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Goswin von Brederlow wrote: and it has numerous RC bugs. Lets see: http://packages.qa.debian.org/i/ia32-libs-tools.html RC bugs: 1 There were 6 bugs when I looked at the page before writing my mail, guess you've merged/downgraded/... the others.I should have added another one - breaking apt completely while removing the ia32 packages is not nice. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Roger Leigh rle...@codelibre.net writes: On Sun, Jul 05, 2009 at 11:36:31PM +0200, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: As I see it, there are two major hurdles: 1) Initial creation of the chroot. As above, I think a simple script to integrate with the existing tools would work just fine here. Which must handle all possible user configurations for mail, sound, printing, I'm not sure I agree here. All possible configurations is a rather impossible goal for any system. The creator of any package would need to decide what to support by default. It can use the d-i tasks just like a normal installation would, but the user will ultimately have the power to configure it as they see fit. That isn't what I ment. Or at least I think you misunderstood. If the user has configured his sound outside the chroot to for example use a network sound daemon and play on another host then inside the chroot the sound should do the same. Or when sound is used outside the chroot by e.g. kopete to beep when a new message comes in then sound should still work for a 32bit flash inside the chroot. And so on. There are a number of things that should be passed from the chroot to the real system and each has tons of different possibilities for the user to configure them. Makeing them work out of the box inside the chroot is shear impossible. And if the solution doesn't work out of the box but needs lengthly manual configuration and tinkering then that isn't a solution. Although I use amd64, I have yet to want to install any 32bit software, so I'm not entirely sure what the use case is for it. If we're talking about specific programs such as proprietary binary- only software and browser plugins etc., then we really only need the specific software and its dependencies in there. I really don't see the need for an entire functional desktop environment inside the chroot, for example. Some further clarification is needed here. It doesn't need an entire functional desktop environment, it just should be entirely functioning. Having a 32bit browser and flash plugin in a chroot is of little use if you don't have sound while kopete is running outside the chroot. 2) An easy way to run programs inside the chroot. This depends upon exactly what you want to do. Wrapper scripts or shell aliases do a good job for existing users; automatically generated desktop menu files for specific applications would also work. Which then can't generaly send mail, play sound nicely (mix with the non-chroot sound), print documents, ... These tasks just require the necessary client libraries and/or programs to talk to the server. In the case of the sound, the device nodes are shared with the host system, as is SYSV and POSIX SHM. For server AF_LOCAL sockets, we can bind mount the sockets in there as well. Yes, you can. It just means do this, and that and that other thing. And then the user uninstalls sound system A and installs sound system B and suddenly the old bind mount is inefective since it mounts the wrong directory. And most unsovably: You can not start 64bit programs from inside the 32bit chroot again, have them start 32bit, 64, 32, 64, 32, ... How many levels bind mounts do you want to do? Well, from a kernel POV, you can certainly use personality(2) to switch the execdomain back to PER_LINUX from PER_LINUX32. You are correct that starting 64bit programs on the host from inside the chroot is not possible. The isolation of the filesystem from the host is, of course, the defining feature of a chroot environment. If we are running specific programs inside only, is this a problem in practice? How would you write a frontend so that it ensures any program the 32bit applications might want to start are available? Like cups for printing. You pretty quickly come to the conclusion that you need to install every binary in both 64bit and 32bit to be sure. It's certainly possible to install schroot inside the chroot and then chroot back into a virtual host system, but I do admit that's rather gross! While I agree that chroots do appear more technical and fiddly to set up, the reality is that we now have the means to set them up in a reliable and automated fashion, and this will give the user a more robust environment than a monolithic library package set from a security POV, as well as giving them access to the /entire/ archive rather than a restricted subset, making it rather more useful. While multiarch should solve this problem, chroots offer rather more functionality and reliability at the present time, with a (rather small) hurdle to set up initially. Not in a way that is suitable for general desktop applications. And hey, here is this existing way of doing all this so that none of these problems arise: ia32-apt-get. It also is not monolithic, nor a security problem and also gives access to the full
Re: ia32-libs{-tools}, multiarch, squeeze
Bernd Zeimetz be...@bzed.de writes: Goswin von Brederlow wrote: and it has numerous RC bugs. Lets see: http://packages.qa.debian.org/i/ia32-libs-tools.html RC bugs: 1 There were 6 bugs when I looked at the page before writing my mail, guess you've merged/downgraded/... the others.I should have added another one - breaking apt Most importantly fixed in an upload or assigned to the package that did the actual breaking. I got a number of non-bugs caused by libc6-i386 changing lib32 from link to directory too: Like lib32nss-mdns being uninstallable because libc6-i386 conflicts with it. completely while removing the ia32 packages is not nice. Pray tell, what breaks? 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{-tools}, multiarch, squeeze
Le vendredi 03 juillet 2009 à 14:59 +0200, Goswin von Brederlow a écrit : Do you *really* want to have more reasons? I would settle for one good one. :) OK, let’s try one that you can understand. Try picturing a bridge. ia32-libs-tools is trying to cross the bridge, but there is Ganneff standing on the bridge wearing full armor, saying “None shall pass”. And ia32-libs-tools is not wearing Excalibur. -- .''`. 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{-tools}, multiarch, squeeze
Josselin Mouette j...@debian.org writes: Le vendredi 03 juillet 2009 à 14:59 +0200, Goswin von Brederlow a écrit : Do you *really* want to have more reasons? I would settle for one good one. :) OK, letâs try one that you can understand. Try picturing a bridge. ia32-libs-tools is trying to cross the bridge, but there is Ganneff standing on the bridge wearing full armor, saying âNone shall passâ. And ia32-libs-tools is not wearing Excalibur. More acruate there is this angry mob with torches and pitchforks that chaces ia32-libs-tools back after Ganneff did let it pass. And hey, the good reason was diverting the package management tools is unacceptable. But, no, we have to do insults instead of arguing. 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{-tools}, multiarch, squeeze
Goswin von Brederlow wrote: And hey, the good reason was diverting the package management tools is unacceptable. But, no, we have to do insults instead of arguing. Alas, despite the diversion of the package management tools, I find ia32- apt-get pretty useful. For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript engine). With ia32-apt-get, I could install the 32bit version of my GTK theme engine so that Firefox can look good. Is there a design problem in converting 32bits libraries to ia32-* packages or the sole problem is the diversion of apt-get and co? If there's no design flaw, wouldn't ia32-archive be the correct path? I mean a system to install converted packages which is set apart the package management system (until the actual package installation of course)? 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{-tools}, multiarch, squeeze
Yannick yannick.roeh...@free.fr writes: Goswin von Brederlow wrote: And hey, the good reason was diverting the package management tools is unacceptable. But, no, we have to do insults instead of arguing. Alas, despite the diversion of the package management tools, I find ia32- apt-get pretty useful. For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript engine). With ia32-apt-get, I could install the 32bit version of my GTK theme engine so that Firefox can look good. Is there a design problem in converting 32bits libraries to ia32-* packages or the sole problem is the diversion of apt-get and co? There where 3 minor bug reports about an ia32-* package not working right. Out of an estimate of 160-200 packages people use. I think that is pretty good. All 3 bugs where fix in a subsequent upload and currently there are no reported missconversions. On the other hand ~45 bugs about missconversion or missing packages in the old ia32-libs where closed (and will have to be reopened now). So I don't believe there is a design problem there. That part works just fine. But the diversions had people totaly in outrage. So much so that I believe they didn't even look past that at all. If there's no design flaw, wouldn't ia32-archive be the correct path? I mean a system to install converted packages which is set apart the package management system (until the actual package installation of course)? I thought so. But people will have to live with no 32bit support or the old ia32-libs monster when Mark uploads it again as the default. Yannick 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{-tools}, multiarch, squeeze
On Fri, Jul 03, 2009 at 01:18:14AM +0200, Goswin von Brederlow wrote: There is only one thing that DAK might want to adapt to. For most multiarch architectures there is a definite main architecture that most things should be in and then some corner cases where different architetcure might be prefered or required. Usualy because 32bit mode has smaller code and is faster than 64bit mode but sometimes the larger addresss space of 64bit mode is required. So there might be a need to introduce partial architectures for ppc64, mips64, mips64el, sparc64 that only carry a small subset of Debian. The change would be in policy to allow architecture that are partial and maybe some code to reject unwanted packages from those architectures. + s390x I would encourage people interested in these architectures to work on developing such a policy, building on top of the current multiarch spec. This isn't critical-path for delivering an initial multiarch implementation for squeeze, but I see no reason that it couldn't be worked on in parallel. -- 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{-tools}, multiarch, squeeze
Goswin von Brederlow wrote: Please do files bugs about issues you consider blockers for ia32-libs-tools and squeeze and please include if that applies even if there is the old ia32-libs in parallel to it (i.e. when it doesn't get pulled in on upgrades). The package is a mess, the idea is broken by the design and it has numerous RC bugs. Do you *really* want to have more reasons? -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Steve Langasek vor...@debian.org writes: On Fri, Jul 03, 2009 at 01:18:14AM +0200, Goswin von Brederlow wrote: There is only one thing that DAK might want to adapt to. For most multiarch architectures there is a definite main architecture that most things should be in and then some corner cases where different architetcure might be prefered or required. Usualy because 32bit mode has smaller code and is faster than 64bit mode but sometimes the larger addresss space of 64bit mode is required. So there might be a need to introduce partial architectures for ppc64, mips64, mips64el, sparc64 that only carry a small subset of Debian. The change would be in policy to allow architecture that are partial and maybe some code to reject unwanted packages from those architectures. + s390x I would encourage people interested in these architectures to work on developing such a policy, building on top of the current multiarch spec. This isn't critical-path for delivering an initial multiarch implementation for squeeze, but I see no reason that it couldn't be worked on in parallel. Last I heart s390 planed to drop 31bit support and go fully 64bit. 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{-tools}, multiarch, squeeze
On Fri, Jul 03, 2009 at 10:28:24AM +0200, Goswin von Brederlow wrote: Last I heart s390 planed to drop 31bit support and go fully 64bit. This was the plan. However I don't know if it is the best solution. The fact is: only Debian and SuSE still supports a complete 31bit userland. RHEL is released 64bit only with some 31bit libs and SuSE have both. This also means that many of the commercial software is now released as 64bit binaries. On s390 we have the advantage that we have a lot more operations in 64bit aka zarch mode while using the same opcode format. This includes things like 32bit immediate loads and, for z9 and newer only, unicode conversion[1]. So this code can actually be smaller and faster then the 31bit code. So if we are going to get multiarch support, I would vote for a two stage plan: - Do a full 31 and 64bit release for X. - Reduce the 31bit port to minimal for X+1. I hope that apt e.g. will be able to do such an upgrade. Bastian [1] https://bblank.thinkmo.de/blog/s390-assembler, https://bblank.thinkmo.de/blog/smallest-utf32-to-utf8-converter -- But Captain -- the engines can't take this much longer! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Bastian Blank wa...@debian.org writes: On Fri, Jul 03, 2009 at 10:28:24AM +0200, Goswin von Brederlow wrote: Last I heart s390 planed to drop 31bit support and go fully 64bit. This was the plan. However I don't know if it is the best solution. The fact is: only Debian and SuSE still supports a complete 31bit userland. RHEL is released 64bit only with some 31bit libs and SuSE have both. This also means that many of the commercial software is now released as 64bit binaries. On s390 we have the advantage that we have a lot more operations in 64bit aka zarch mode while using the same opcode format. This includes things like 32bit immediate loads and, for z9 and newer only, unicode conversion[1]. So this code can actually be smaller and faster then the 31bit code. So if we are going to get multiarch support, I would vote for a two stage plan: - Do a full 31 and 64bit release for X. - Reduce the 31bit port to minimal for X+1. I hope that apt e.g. will be able to do such an upgrade. Bastian [1] https://bblank.thinkmo.de/blog/s390-assembler, https://bblank.thinkmo.de/blog/smallest-utf32-to-utf8-converter -- I guess that means introducing a full s390x architecture then and eventually making s390 the partial architecture. You can start on the first part for squeeze. :) 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{-tools}, multiarch, squeeze
Bernd Zeimetz be...@bzed.de writes: Goswin von Brederlow wrote: Please do files bugs about issues you consider blockers for ia32-libs-tools and squeeze and please include if that applies even if there is the old ia32-libs in parallel to it (i.e. when it doesn't get pulled in on upgrades). The package is a mess, Specifics. Not just ranting please. the idea is broken by the design Not in my opinion. Works perfectly here. and it has numerous RC bugs. Lets see: http://packages.qa.debian.org/i/ia32-libs-tools.html RC bugs: 1 #535486 ia32-libs breaks multiarch buildd and adds useless dependency The fix for this is for fglrx to stop building fglrx-glx-ia32 and letting ia32-apt-get provide the 32bit fglrx-grl package from i386 instead. Purely a transitional issue. It doesn't even break the buildd. It just takes really long to install if you don't have a strong enough source for entropy. Do you *really* want to have more reasons? I would settle for one good one. :) 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{-tools}, multiarch, squeeze
Joerg Jaspert jo...@debian.org writes:
Hello world,
(Please remember that we can only speak for ourselves and not the
security/release/any other teams, individuals or other sentient beings.)
During the recent discussion about about ia32-libs{,-gtk,-tools} there were
various requests for removal / comments about ftpmaster requirements for the
whole ia32-libs situation.
Having looked at the situation both in lenny and in sid, we tend to agree that
ia32-libs-tools in its current form is unacceptable. It was mentioned in the
Please do files bugs about issues you consider blockers for
ia32-libs-tools and squeeze and please include if that applies even if
there is the old ia32-libs in parallel to it (i.e. when it doesn't get
pulled in on upgrades).
threads that comments had been received from ftpmaster that the lenny form of
ia32-libs (the one where all the source is duplicated in two huge packages -
ia32-libs and ia32-libs-gtk) was disliked. This remains the case but it is
still preferable (both to us, and it seems to the majority of the rest of the
project) than the ia32-libs-tools approach.
Given that there are definitely use-cases for some form of ia32-libs, we
suggest that a version of ia32-libs{-gtk} is re-uploaded to Debian, replacing
the current ia32-libs-tools. This needs agreement with the release and
security teams, as this most probably will have to be supported for squeeze in
some form (even if that includes admitting that we have no security support
for
the binary ia32-libs packages).
Also an agreement from Bdale Garbee bd...@gag.com and/or Frederik
Schüler f...@debian.org to remain its maintainer or another
volunteer.
The recent discussions on doing multiarch properly look promising and, even
better, there seems to be broad consensus that this is the right longer-term
direction. The question is whether the first round could be ready for squeeze
so that we don't have to ship ia32-libs again. This obviously depends on
people wanting (and having time) to work on it; hopefully more will be known
after the planned BoF at DebConf. Just to make it clear, there are no
objections at all from ftpmaster to multiarch and we will make sure that any
archive-side changes which may be necessary will be performed so that we don't
block it (although looking at the current proposal from Steve Langasek et al,
we can't really see anything which should need changing).
As per design. :)
There is only one thing that DAK might want to adapt to. For most
multiarch architectures there is a definite main architecture that
most things should be in and then some corner cases where different
architetcure might be prefered or required. Usualy because 32bit mode
has smaller code and is faster than 64bit mode but sometimes the
larger addresss space of 64bit mode is required.
So there might be a need to introduce partial architectures for ppc64,
mips64, mips64el, sparc64 that only carry a small subset of
Debian. The change would be in policy to allow architecture that are
partial and maybe some code to reject unwanted packages from those
architectures.
This should drop the surprising effects users of the ia32-libs-tools packages
experienced in the last few days and also allow us to continue supporting
users
of the 32 bit libraries.
I hope most surprises are addresses in the current version, at least
those that aren't as designed. Please do continue to file bugs when
you run into something so it can be addressed in the package and other
people are spared from the surprise in the future.
This is, as ever, not a statement of the future, but suggestions and thoughts
on the matter. It has mainly been written due to the fact that we have been
asked by multiple people to remove ia32-libs-tools but don't want to do so
until a consensus has been reached on what we're going to do to replace it.
Thanks,
--
bye, Joerg
Md Sesse: I doubt that many people will switch network
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
