Re: multiarch/bi-arch status (ETA) question
On Fri, Jul 08, 2005 at 08:23:10PM +0200, Goswin von Brederlow wrote: > > $ apt-cache show liferea-mozilla > > [...] > > Depends: liferea (= 0.9.1-1), mozilla-browser, [...] > > > > Gabor > > Does that dlopen mozilla? Looking at the /proc/.../maps file it does. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Miroslav Maiksnar <[EMAIL PROTECTED]> writes: > Dne st 6. Äervence 2005 22:16 Hugo Mills napsal(a): >> On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote: >> > It is impossible to install two packages that contain the same >> > filename. Libraries use /usr/lib/arch-os/ to make libs differ between >> > archs. >> >>That's not _entirely_ true. In Tollef's multiarch proposal, files >> in /usr/share/doc/ can indeed overlap between packages with >> precisely the same name differing only in architecture. My preliminary >> patches to dpkg supported that behaviour. > > Wouldn't be better have /usr/share/doc/// directories? No > files will be overlapping and all libs will have it's own copyright and > README files (which may differ between different arch-os combinations). > > Mixi If there is any larger overlap in /usr/share/doc// then the package should be split into architecture dependend and independend packages. Also /usr/share is shareable between architecture by policy and fhs so file differences between architectures would be RC bugs imho. The alowed overlap is for the /usr/share/doc//copyright and changelog files, which must be present on both archs. But splitting a package into architecture dependend and independend packages just for those 2 files (or 3 with a README) would be a bit insane so a exception has been made and overlaps there are allowed. This is a compromise so as not to needlessly create new packages. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On 7/8/05, Miroslav Maiksnar <[EMAIL PROTECTED]> wrote: > Wouldn't be better have /usr/share/doc/// directories? No > files will be overlapping and all libs will have it's own copyright and > README files (which may differ between different arch-os combinations). No, I don't think so. The idea of /usr/share is that it does not depend on the architecture. If a README is architecture specific, it should be called README.. It can be included for all packages, or just for the specific architecture. Otherwise we end up splitting all directory, and then we could just as well use a chroot environment :-) Thomas
Re: multiarch/bi-arch status (ETA) question
Dne st 6. července 2005 22:16 Hugo Mills napsal(a): > On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote: > > It is impossible to install two packages that contain the same > > filename. Libraries use /usr/lib/arch-os/ to make libs differ between > > archs. > >That's not _entirely_ true. In Tollef's multiarch proposal, files > in /usr/share/doc/ can indeed overlap between packages with > precisely the same name differing only in architecture. My preliminary > patches to dpkg supported that behaviour. Wouldn't be better have /usr/share/doc/// directories? No files will be overlapping and all libs will have it's own copyright and README files (which may differ between different arch-os combinations). Mixi
Re: multiarch/bi-arch status (ETA) question
David Wood <[EMAIL PROTECTED]> writes: > On Fri, 8 Jul 2005, Goswin von Brederlow wrote: > >> 3rd party software is nearly completly 32bit and our 32bit libs are >> already in the wrong place for rpath then. We can move >> /emul/ia32-libs/lib/* to /lib/i486-linux/ (same for usr/lib in all >> cases) without changing anything. >> >> We can also move /lib/* to /lib/x86_64-linux/* and adjust the /lib64 >> compatibility link without changing anything. That even works for >> rpath. >> >> We can even link /lib/i486-linux -> ., placing the 32bit libs in /lib >> to preserve rpath for both 32bit and 64bit. > > So, if I can go back to my original question: what are the blockers > for a package maintainer who wants to get started with multiarch? It > sounds like just some symlinks in base packages are all that need to > change... and I repeat my answere: gcc, binutils, libtools, automake, autoconf. Toolchain issues. By all means move your lib around in your package and try them out. Recompile any rdepends your lib has. You will notice if something has problems. But I suggest not uploading those changes just yet. With all the transitions going on currently risking breakage you didn't test for would be bad. FYI: If I can convince the dpkg maintainer then I will add DEB_HOST_LIBDIR, DEB_HOST_LIB32DIR and DEB_HOST_LIB64DIR to dpkg-architecture. That way sources can use those variables to build and install their files already and when we decide the toolchain is all ready for multiarch dpkg-architecture changes the paths. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
GOMBAS Gabor <[EMAIL PROTECTED]> writes: > On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote: > >> Also programs don't depend on something like galeon (i hope). > > $ apt-cache show liferea-mozilla > [...] > Depends: liferea (= 0.9.1-1), mozilla-browser, [...] > > Gabor Does that dlopen mozilla? In that case it needs to specify the architecture it needs (only if mozilla sets "Multi-arch: no"). If it just fork()s and exec()s mozilla then an abi change is perfectly fine. Mozilla might even never convert over to "Multi-arch: no" given that it has so many plugins and is very high in dependency trees. This is one thing that is unsaid or unclear in the multiarch proposal. Packages can have one of 3 types: 1. Multi-arch: yes This is a library package. Any number of architectures of this package can be installed at the same time and packages depending on it require the same abi to fullfill the depends. E.g. libc6 2. Multi-arch: no This is a program with command line interface. Only one architecture of this package can be installed and packages depending on this will work with any arch. E.g. make 3. no Multi-arch entry This package is not multiarch aware/ready/capable. All existing packages fall into this case and backwards compatibility has to be maintained. We can't assume anything about this package and that means: - only one architecture of this package can be installed - packages depending on it require the same abi (this could be a lib) At the start all packages are type 3. That means that you can only install debconf 32bit or 64bit but not both. In turn, if you have 32bit debconf installed, you can only install 32bit flavours of anything with Depends: debconf. Since that is a big pain debconf (and any other frequently depended upon program) have to change to type 2 (which means _only_ adding that one line in control). This sounds like a lot of unneccesary work (hey, why not assume type 2 if unset?) but it is the only way that will not break existing packages. Think about it for a while before you reply. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
GOMBAS Gabor <[EMAIL PROTECTED]> writes: > On Wed, Jul 06, 2005 at 02:33:39AM +0200, Goswin von Brederlow wrote: > >> Configure scripts have sometimes hardcoded paths to /usr/lib. > > And /usr/include. Don't forget that some packages install > architecture-specific header files under /usr/include. > >> Libtool adds rpath if libraries are not in default system paths and >> rpath means incompatibility to every other linux out there. > > Well, libtool can be taught that the new directories are also default > system paths, then you "only" have to re-libtoolize everything. Quite > some work but doable. > > Gabor Hence my plea to fix the toolchain packages first. Pick a few sample libs, change them and see what toolchain makes problems. Fix that and send in the toolchain patch. And only after that send in the patches for the libs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Hugo Mills <[EMAIL PROTECTED]> writes: > On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote: >> Stephan Seitz <[EMAIL PROTECTED]> writes: >> >> > On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote: >> >>We are not saying you shouldn't make binaries coinstallable for >> >>multiple archs, we are only saying we won't make this a policy. It is >> >>left to each package maintainer to decide if he wants to make the >> >>multiarch change for his binary too or not and nearly every one will >> >>not. >> > >> > All right, this is a solution I can live with. Until now I thought, >> > that it would be impossible, even with multiarch, to install two >> > programs together. >> >> It is impossible to install two packages that contain the same >> filename. Libraries use /usr/lib/arch-os/ to make libs differ between >> archs. > >That's not _entirely_ true. In Tollef's multiarch proposal, files > in /usr/share/doc/ can indeed overlap between packages with > precisely the same name differing only in architecture. My preliminary > patches to dpkg supported that behaviour. I think it is best to ignore this special case used for the copyright and changelog files in the general discussions. /usr/share/doc is special in that packages may not depend on it being there at all and messups there (like files disapearing if one of two archs of a package is purged) may not have affects on the package. >> Also programs don't depend on something like galeon (i hope). > >Yes, this is an assumption of Tollef's proposal. Actually, it's > that programs don't depend on galeon *and care what the architecture > of that package is*. (I think... don't hold me to that... :) ) > >Hugo. Yes, things that depend on make have to work with either make flavour. If that is ever not the case then the depends has to be specialized to include the architecture required (like plugins will need to). The assumption is that only a very, very small fraction of packages will need this change and the breakage of old versions of those is neglible. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Fri, 8 Jul 2005, Goswin von Brederlow wrote: 3rd party software is nearly completly 32bit and our 32bit libs are already in the wrong place for rpath then. We can move /emul/ia32-libs/lib/* to /lib/i486-linux/ (same for usr/lib in all cases) without changing anything. We can also move /lib/* to /lib/x86_64-linux/* and adjust the /lib64 compatibility link without changing anything. That even works for rpath. We can even link /lib/i486-linux -> ., placing the 32bit libs in /lib to preserve rpath for both 32bit and 64bit. So, if I can go back to my original question: what are the blockers for a package maintainer who wants to get started with multiarch? It sounds like just some symlinks in base packages are all that need to change... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
[EMAIL PROTECTED] (Lennart Sorensen) writes: > If we could ignore rpath problems, then moving everything to an arch dir > under each lib dir would take care of the libs since the ld loader can > handle the new locations. Building software may or may not work since > configure scripts might get confused, but then again they often do. > > Len Sorensen We can and will ignore rpath problems. We are already doing so. 3rd party software is nearly completly 32bit and our 32bit libs are already in the wrong place for rpath then. We can move /emul/ia32-libs/lib/* to /lib/i486-linux/ (same for usr/lib in all cases) without changing anything. We can also move /lib/* to /lib/x86_64-linux/* and adjust the /lib64 compatibility link without changing anything. That even works for rpath. We can even link /lib/i486-linux -> ., placing the 32bit libs in /lib to preserve rpath for both 32bit and 64bit. So, as amd64 owner, we are very lucky here. What I'm concerned about is source compatibility. Configure scripts will need to adjust to the new locations as well as gcc and binutils. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Bob Proulx ([EMAIL PROTECTED]) wrote:
>> Goswin von Brederlow wrote:
>> > Hugo Mills <[EMAIL PROTECTED]> writes:
>> > >How? You can't install your two multiarch versions of libvorbis
>> > > without a hacked package manager that understands how to do it.
>> >
>> > You name packages lib32foo and lib64foo or something non
>> > conflicting. Or you use the multiarch patch for dpkg.
>>
>> I really don't like needing to change the package names to be uniquely
>> named. I think for multiarch to really work in Debian then dpkg needs
>> to have a split brain where the architecture specific packages are
>> tracked separately.
>
> I think that's what Goswin was saying ("Or you use the multiarch patch
> for dpkg."). I thought the original idea was to have the package names
> be the same actually. I don't know that it'd be a big deal either way
> though.
>
> Thanks,
>
> Stephen
Yes, that is what I ment. The renaming is just to test the package
without having to need a multiarch capable package management.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
[EMAIL PROTECTED] (Bob Proulx) writes: > Thomas Steffen wrote: >> The better way to do it is to have three (sub)packages: i386, x86_64 >> and shared. That is a bit like -common and -bin, but the packages >> differ only in architecture, not in the name. Imho that is the way to >> go. >> >> However, if you look closer, you find that both approaches impose the >> same restrictions: all two or three (sub)packages have to be exactly >> the same version, they have to match. So you can't upgrade one without >> upgrading the other(s). > > That all depends on if the relationship is == or >=. It shouldn't if > it is a >= dependency. But I am not sure that is practical for > /usr/share files in general. But splitting that many packages would > certainly increase the number of descrete packages hugely. It also isn't a problem for debian. There are lots of packages that are already interlocked with a 'foo (= 1.2-3)' depends and apt and friends know how do deal with those without any problems. Every library package is already interlocked with its -dev counterpart that way. >> I think this severely limits the ability to install third-party i386 >> software on a RedHat x86_64 system. As soon as the third-party >> software requires a library upgrade, you get conflicts. (Now that >> problem isn't new either, it is the reason behind DLL hell...) Debian takes great care in changing SONAME and ABINAME whenever they need changing. That means that things don't break when you have to upgrade a library and different sonames of a library are usualy made to coexist. > But wait, most people who install RH systems don't actually ever > upgrade. At the time they put the install cdrom in the box they > install everything because they have been taught by experience that > upgrades later don't work, better grab it now. So if they go to > install something later it needs a newer library they consider that > application completely unsupported on version X and think "I need to > reinstall the system from scratch to get to version Y so that this > application will run", no matter how trivial the requirement. > > Bob MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Thu, Jul 07, 2005 at 05:32:45PM +0200, Thomas Steffen wrote: > I wouldn't call that just fine. Setting the environment variables > means that you break any 64bit process that Openoffice might want to > spawn, which is a certain way to get really strange bugs. I bet that > printing using kprinter does not work, for example. I do not have a printer, and I do not use KDE :-) > > The only remaining problem is a "Locale not supported by the C library, > > falling back to C" message that I could not track down so far. > > Does that mean you consider a system without localisation working? It turned out to be a version skew between the 32-bit and 64-bit glibc. glibc-2.3.2(i386) did not like the locale-archive from glibc-2.3.5(amd64). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote: > Also programs don't depend on something like galeon (i hope). $ apt-cache show liferea-mozilla [...] Depends: liferea (= 0.9.1-1), mozilla-browser, [...] Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, Jul 06, 2005 at 02:33:39AM +0200, Goswin von Brederlow wrote: > Configure scripts have sometimes hardcoded paths to /usr/lib. And /usr/include. Don't forget that some packages install architecture-specific header files under /usr/include. > Libtool adds rpath if libraries are not in default system paths and > rpath means incompatibility to every other linux out there. Well, libtool can be taught that the new directories are also default system paths, then you "only" have to re-libtoolize everything. Quite some work but doable. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On 7/7/05, GOMBAS Gabor <[EMAIL PROTECTED]> wrote: > Well, Vmware runs just fine without any kind of chroot. Yes, I did get the test version of VMware running, but it was not without issues. > OOo also runs > fine if you just _install_ it in a chroot but call it from the outside > (well, you need to set a bunch of environment variables that point to > the 32-bit gconv modules, 32-bit GTK theme, 32-bit GTK & Pango modules > etc., and some bind mounts for /etc/openoffice and /usr/lib/openoffice > that cannot be relocated by environment variables). I wouldn't call that just fine. Setting the environment variables means that you break any 64bit process that Openoffice might want to spawn, which is a certain way to get really strange bugs. I bet that printing using kprinter does not work, for example. On the bright side: Ubuntu actually got Openoffice to work, mostly at least. But they had to write some code for it, it seems. > The only remaining problem is a "Locale not supported by the C library, > falling back to C" message that I could not track down so far. Does that mean you consider a system without localisation working? Coming from a country with a latin1 alphabet it is hard for me to understand what it is like to use UTF8. But there are enough countries where UTF8 is the only reasonable choice. Konsole for example is half way broken, even in 3.4. > So 32-bit apps seem to work without a chroot; you only need the chroot > for package management. I guess we wouldn't have the discussion if it did work, so I can only conclude that the majority of users (and you only see the extreme early adopters here) are of a different opinion. Thomas
Re: multiarch/bi-arch status (ETA) question
On Thu, 7 Jul 2005, Bob Proulx wrote: I really don't like needing to change the package names to be uniquely named. I think for multiarch to really work in Debian then dpkg needs to have a split brain where the architecture specific packages are tracked separately. I think he just means for testing pruposes - not actually as something you would deploy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
* Bob Proulx ([EMAIL PROTECTED]) wrote:
> Goswin von Brederlow wrote:
> > Hugo Mills <[EMAIL PROTECTED]> writes:
> > >How? You can't install your two multiarch versions of libvorbis
> > > without a hacked package manager that understands how to do it.
> >
> > You name packages lib32foo and lib64foo or something non
> > conflicting. Or you use the multiarch patch for dpkg.
>
> I really don't like needing to change the package names to be uniquely
> named. I think for multiarch to really work in Debian then dpkg needs
> to have a split brain where the architecture specific packages are
> tracked separately.
I think that's what Goswin was saying ("Or you use the multiarch patch
for dpkg."). I thought the original idea was to have the package names
be the same actually. I don't know that it'd be a big deal either way
though.
Thanks,
Stephen
signature.asc
Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
Goswin von Brederlow wrote: > Hugo Mills <[EMAIL PROTECTED]> writes: > >How? You can't install your two multiarch versions of libvorbis > > without a hacked package manager that understands how to do it. > > You name packages lib32foo and lib64foo or something non > conflicting. Or you use the multiarch patch for dpkg. I really don't like needing to change the package names to be uniquely named. I think for multiarch to really work in Debian then dpkg needs to have a split brain where the architecture specific packages are tracked separately. Bob signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
Goswin von Brederlow wrote: > [EMAIL PROTECTED] (Bob Proulx) writes: > > This has been a long standing behavior of rpm that is now > > exploited for use in biarch. > > That sounds like there is no special biarch support at all in rpm but > just the support to have multiple versions of a package installed and > incidentaly that can be used for this too. Lucky break for rpm I > guess. > > This is quite similar to very early biarch proposals. Mostly I believe that to be true. But the dependency management seems to be split into an architecture specific area. Not sure of the underlying details. > > depends upon 'libm.so.6()(64bit)' fine. > > Now that '(64bit)' is something they had to add for biarch support. I believe that is the only addition for biarch support. I can't see anything else different from the outside of the box. > There was talk about doing the same for multiarch early on but it > breaks backwards compatibility, i.e. old packages that don't have the > (64bit) will break. Hmm... I think the (64bit) only exists on packages built for amd64. The 32-bit packages of course don't have it since those are from pure 32-bit single architecture systems. So I think it is only the newly built 64-bit packages that state that dependency. > We improved that by having libraries state "Multiarch: yes" and have > dpkg then match the arch of the lib and depending package to see if > thats enough. Interesting. Bob signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
Thomas Steffen wrote: > The better way to do it is to have three (sub)packages: i386, x86_64 > and shared. That is a bit like -common and -bin, but the packages > differ only in architecture, not in the name. Imho that is the way to > go. > > However, if you look closer, you find that both approaches impose the > same restrictions: all two or three (sub)packages have to be exactly > the same version, they have to match. So you can't upgrade one without > upgrading the other(s). That all depends on if the relationship is == or >=. It shouldn't if it is a >= dependency. But I am not sure that is practical for /usr/share files in general. But splitting that many packages would certainly increase the number of descrete packages hugely. > I think this severely limits the ability to install third-party i386 > software on a RedHat x86_64 system. As soon as the third-party > software requires a library upgrade, you get conflicts. (Now that > problem isn't new either, it is the reason behind DLL hell...) But wait, most people who install RH systems don't actually ever upgrade. At the time they put the install cdrom in the box they install everything because they have been taught by experience that upgrades later don't work, better grab it now. So if they go to install something later it needs a newer library they consider that application completely unsupported on version X and think "I need to reinstall the system from scratch to get to version Y so that this application will run", no matter how trivial the requirement. Bob signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
On Tue, Jul 05, 2005 at 05:26:46PM +0200, Thomas Steffen wrote: > No, for all practical purposes you do not have that. I could not get a > single third part binary to work without a chroot. And recommending a > chroot is just a different way of saying that it is not supported. Well, Vmware runs just fine without any kind of chroot. OOo also runs fine if you just _install_ it in a chroot but call it from the outside (well, you need to set a bunch of environment variables that point to the 32-bit gconv modules, 32-bit GTK theme, 32-bit GTK & Pango modules etc., and some bind mounts for /etc/openoffice and /usr/lib/openoffice that cannot be relocated by environment variables). The only remaining problem is a "Locale not supported by the C library, falling back to C" message that I could not track down so far. So 32-bit apps seem to work without a chroot; you only need the chroot for package management. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Thu, Jul 07, 2005 at 04:10:46AM +0200, Goswin von Brederlow wrote: > That why you read Toleffs proposal for multiarch for debian fo details. > > You name packages lib32foo and lib64foo or something non > conflicting. Or you use the multiarch patch for dpkg. How about mips? They have 3 architectures supported on newer machines. two 32bit and one 64bit architecture. :) Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Hugo Mills <[EMAIL PROTECTED]> writes: > On Wed, Jul 06, 2005 at 11:46:12AM -0400, David Wood wrote: >> On Wed, 6 Jul 2005, Hugo Mills wrote: >> >> > They're not (directly) the way that the Debian multiarch is most >> >likely to go. Unfortunately, the relevant site seems to be down, but >> >take a look at [1], and possibly some of the other (Google cached) >> >files in [2]. >> >> Just out of curiosity; does anyone know what was wrong with the >> way documented in: >> >> http://www.linuxbase.org/futures/ideas/multiarch/ > >It's pretty vague, since it doesn't deal with any of the problems > of actually implementing those (fairly high-level) suggestions in any > given package management system. That why you read Toleffs proposal for multiarch for debian fo details. >> On Wed, 6 Jul 2005, Hugo Mills wrote: >> >> >>If I may venture a little further, the idea that all of this must be done >> >>in one giant atomic effort is apparently very popular... why? >> > >> > Because you can't demonstrate that your modified packages are >> >actually going to work properly (and in fact, they won't, if you make >> >only the modifications you propose) without having a working >> >multiarch-aware packaging system to test them with. >> >> Sure you can. Just test them. > >How? You can't install your two multiarch versions of libvorbis > without a hacked package manager that understands how to do it. You name packages lib32foo and lib64foo or something non conflicting. Or you use the multiarch patch for dpkg. >> It sounds like you want to maintain two sets of packages: one normal, one >> fixed for multiarch. Is that really easier than just making the links, >> updating your existing set of packages over time, and doing verification >> on a pre-release multiarch systems with increasing aggressiveness until a >> multiarch release? Over time means something in the order of 3-6 years. And multiarch as proposed does it without any link farms. >You make it sound all so simple... > >Might I suggest you present a set of patches for dpkg that allows > the installation of two different architectures of a library in a > consistent and functional manner? I'm certainly willing to talk over > the details with you towards that end. Those should still be on alioth in the biarch tree. >Yes, I'm harping on about the problems of the package manager side > of things, but only because those are the ones I've tried to work on > in the past and know the best. But someone made the proof of concept patch for dpkg already. >Hugo. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
[EMAIL PROTECTED] (Lennart Sorensen) writes: > On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote: >> Because there are so very few plugin using programs that need that at >> all and changing 16K packages just so maybe 20 packages don't have to >> do something special is rather pointless. >> >> Feel free to change mplayer to use /usr/bin/i386 and /usr/bin/amd64 or >> use mplayer.i386 and mplayer.amd64 and an alternative for mplayer. The >> change is easy to make for packages that need it and realy useless for >> everything else. >> >> >> We are not saying you shouldn't make binaries coinstallable for >> multiple archs, we are only saying we won't make this a policy. It is >> left to each package maintainer to decide if he wants to make the >> multiarch change for his binary too or not and nearly every one will >> not. > > If you did allow it, you could almost have a single nfs server handle > all package installs for multiple architectures (as long as postinst and > company could run on the server arch). Doesn't really fit into what > multiarch is for, but could be neat. > >> The only binaries people wanted in 32/64 bit so far are all plugin >> using binaries where the plugins are only available in 32bit. A very >> small subset of all packages. > > Perhaps, but wouldn't it be nice to have a solution that handles it for > any package without even changing the packages? > > Len Sorensen Find one that doesn't involve realy dirty hacks. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, 6 Jul 2005, Hugo Mills wrote: It's pretty vague, since it doesn't deal with any of the problems of actually implementing those (fairly high-level) suggestions in any given package management system. That doesn't seem to me like something that's wrong. Are you saying something specific in Debian wouldn't work, and couldn't be elegantly made to work, with the scheme? Reading it, I can't see what that would be - but that's not saying much, that's why I'm asking. Sure you can. Just test them. How? You can't install your two multiarch versions of libvorbis without a hacked package manager that understands how to do it. OK... you make whatever changes you expect to make. For the vast majority of packages this is not rocket science. Maybe it's as simple as a change to the ./configure line. You know if they work within the original arch right away. Then when the tools are functional enough you test them in multiarch too. What am I missing? It sounds like you want to maintain two sets of packages: one normal, one fixed for multiarch. Is that really easier than just making the links, updating your existing set of packages over time, and doing verification on a pre-release multiarch systems with increasing aggressiveness until a multiarch release? You make it sound all so simple... Might I suggest you present a set of patches for dpkg that allows the installation of two different architectures of a library in a consistent and functional manner? I'm certainly willing to talk over the details with you towards that end. Yes, I'm harping on about the problems of the package manager side of things, but only because those are the ones I've tried to work on in the past and know the best. I'm not talking about changes to dpkg, so there is really only one question: can it be done? Or put another way, are lib directories moving? I hear yes. So then I think, do we wait for the chicken to appear before we get the egg? Or can we make a trivial change so that modifying packages (a lengthy process involving mostly lots of identical, trivial changes done by many, many package maintainers) can happen while dpkg work progresses? I didn't realize this would be controvertial; I just read it in the multiarch document and wondered why it wasn't happening. Besides, something tells me the dpkg maintainers don't want my (redundant, I think) patch, but Debian could probably use hands fixing the thousands of individual packages... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote: > Stephan Seitz <[EMAIL PROTECTED]> writes: > > > On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote: > >>We are not saying you shouldn't make binaries coinstallable for > >>multiple archs, we are only saying we won't make this a policy. It is > >>left to each package maintainer to decide if he wants to make the > >>multiarch change for his binary too or not and nearly every one will > >>not. > > > > All right, this is a solution I can live with. Until now I thought, > > that it would be impossible, even with multiarch, to install two > > programs together. > > It is impossible to install two packages that contain the same > filename. Libraries use /usr/lib/arch-os/ to make libs differ between > archs. That's not _entirely_ true. In Tollef's multiarch proposal, files in /usr/share/doc/ can indeed overlap between packages with precisely the same name differing only in architecture. My preliminary patches to dpkg supported that behaviour. > Also programs don't depend on something like galeon (i hope). Yes, this is an assumption of Tollef's proposal. Actually, it's that programs don't depend on galeon *and care what the architecture of that package is*. (I think... don't hold me to that... :) ) Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Modern medicine does not treat causes: headaches are not --- caused by a paracetamol deficiency. signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
On Wed, Jul 06, 2005 at 06:18:16PM +0200, Goswin von Brederlow wrote: > David Wood <[EMAIL PROTECTED]> writes: > > You're right, of course, but I don't understand why we should avoid > > doing them. With the new dirs in place and linked from the old > > locations, package conversion can start. Until then, the process waits > > to start. Why wait? > > We shouldn't. We just have to test this very carefully or the fallout > of a bad upload will create too much oposition to including multiarch > patches and slow us down overall. > > Imaging the bad blood you would create if you break libc6. Agreed. It's a very bad idea to hare off into the distance changing library packages left, right & centre if you can't demonstrate with a small set (read: one or two) of packages that it really does work. It may be plainly obvious to you that "simply" changing symlinks will work and be sufficient for the purpose, but it's far from obvious to many other people. It took me quite some time of conversation with others in IRC (primarily Tollef) to understand even some of the issues involved in making this change. As with most wide-ranging changes, it really isn't as simple as it first appears. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Modern medicine does not treat causes: headaches are not --- caused by a paracetamol deficiency. signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
On Wed, 6 Jul 2005, Lennart Sorensen wrote: On Wed, Jul 06, 2005 at 11:46:12AM -0400, David Wood wrote: Something else ugly... Just curious, why would this break: mkdir /usr mkdir /usr/lib ln -s /usr/lib /usr/lib/i386-linux It's "recursive," but it appears functional... Yes but now all the i386 files are also in /usr/lib which would work for compatibility, but then you can't be amd64 compatible (although some would say /lib64 is the way to be amd64 compatible). Yes. This is exactly what I mean. I do not expect to be compatible with both until the work is finished... Only to allow packages to migrate on their own time while still in use. If we could ignore rpath problems, then moving everything to an arch dir under each lib dir would take care of the libs since the ld loader can handle the new locations. Building software may or may not work since With links in place, ld would not even need to be changed except "at the end" or in prerelease multiarch systems (although, maybe, why wait?); the idea is that nothing would, in fact, need to change, until you are ready, while you can simultaneously prepare your packages for the new standard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, Jul 06, 2005 at 11:46:12AM -0400, David Wood wrote: > On Wed, 6 Jul 2005, Hugo Mills wrote: > > > They're not (directly) the way that the Debian multiarch is most > >likely to go. Unfortunately, the relevant site seems to be down, but > >take a look at [1], and possibly some of the other (Google cached) > >files in [2]. > > Just out of curiosity; does anyone know what was wrong with the > way documented in: > > http://www.linuxbase.org/futures/ideas/multiarch/ It's pretty vague, since it doesn't deal with any of the problems of actually implementing those (fairly high-level) suggestions in any given package management system. > On Wed, 6 Jul 2005, Hugo Mills wrote: > > >>If I may venture a little further, the idea that all of this must be done > >>in one giant atomic effort is apparently very popular... why? > > > > Because you can't demonstrate that your modified packages are > >actually going to work properly (and in fact, they won't, if you make > >only the modifications you propose) without having a working > >multiarch-aware packaging system to test them with. > > Sure you can. Just test them. How? You can't install your two multiarch versions of libvorbis without a hacked package manager that understands how to do it. > It sounds like you want to maintain two sets of packages: one normal, one > fixed for multiarch. Is that really easier than just making the links, > updating your existing set of packages over time, and doing verification > on a pre-release multiarch systems with increasing aggressiveness until a > multiarch release? You make it sound all so simple... Might I suggest you present a set of patches for dpkg that allows the installation of two different architectures of a library in a consistent and functional manner? I'm certainly willing to talk over the details with you towards that end. Yes, I'm harping on about the problems of the package manager side of things, but only because those are the ones I've tried to work on in the past and know the best. Hugo. -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Modern medicine does not treat causes: headaches are not --- caused by a paracetamol deficiency. signature.asc Description: Digital signature
RE: multiarch/bi-arch status (ETA) question
"What's the reason for having both versions of a given app installed?" To satisfy multiple dependencies that are "must-be-" -Original Message- From: Stephen Frost [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 05, 2005 1:47 PM To: Lennart Sorensen Cc: David Wood; Hugo Mills; Goswin von Brederlow; debian-amd64@lists.debian.org Subject: Re: multiarch/bi-arch status (ETA) question * Lennart Sorensen ([EMAIL PROTECTED]) wrote: > Of course there is also the issue of how to deal with calling the 32 or > 64bit version of program x if you have both versions installed. Perhaps > a helper tool to say run64bit version of x would deal with that, and > your idea of having symlinks in the original location to a default > version would deal well with that. If not specified you run the one > that has the symlink. What's the reason for having both versions of a given app installed? I'm pretty sure it was decided that was a bad idea and that there wasn't any good use case for it and so we weren't going to try and support it. It just doesn't make sense. > Of course then there is things like data files in /usr/share which are > not architecture specific. If you install the same version of both 32 > and 64bit for a package, then the files should match and just keeping > one copy should be fine. If for some reason you install a different > version of one of them (as would happen during upgrades) how do we > resolve those files? They aren't always seperated into an architecture > all package (which would of course be trivial to handle). Do we divert > the files from the older version somewhere, and then remove it when the > older one is upgraded to match the newer one? No point wasting disk > space on identical files after all. This is only an issue with libraries, and /usr/share should have things which are arch-independent and /usr/lib/ should have arch-dependent things. If packages don't follow that today then they're broken already and need to be fixed. It is true that there can't be multiple things installed with files in the same place, so any /usr/share usage in libraries needs to be split out in a -common package for that library. This isn't an issue for programs because we're not interested in supporting the unjustified case for having the same program both 32bit and 64bit at the same time. Thanks, Stephen
Re: multiarch/bi-arch status (ETA) question
On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote: > Because there are so very few plugin using programs that need that at > all and changing 16K packages just so maybe 20 packages don't have to > do something special is rather pointless. > > Feel free to change mplayer to use /usr/bin/i386 and /usr/bin/amd64 or > use mplayer.i386 and mplayer.amd64 and an alternative for mplayer. The > change is easy to make for packages that need it and realy useless for > everything else. > > > We are not saying you shouldn't make binaries coinstallable for > multiple archs, we are only saying we won't make this a policy. It is > left to each package maintainer to decide if he wants to make the > multiarch change for his binary too or not and nearly every one will > not. If you did allow it, you could almost have a single nfs server handle all package installs for multiple architectures (as long as postinst and company could run on the server arch). Doesn't really fit into what multiarch is for, but could be neat. > The only binaries people wanted in 32/64 bit so far are all plugin > using binaries where the plugins are only available in 32bit. A very > small subset of all packages. Perhaps, but wouldn't it be nice to have a solution that handles it for any package without even changing the packages? Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, Jul 06, 2005 at 11:46:12AM -0400, David Wood wrote: > Something else ugly... Just curious, why would this break: > > mkdir /usr > mkdir /usr/lib > ln -s /usr/lib /usr/lib/i386-linux > > It's "recursive," but it appears functional... Yes but now all the i386 files are also in /usr/lib which would work for compatibility, but then you can't be amd64 compatible (although some would say /lib64 is the way to be amd64 compatible). If we could ignore rpath problems, then moving everything to an arch dir under each lib dir would take care of the libs since the ld loader can handle the new locations. Building software may or may not work since configure scripts might get confused, but then again they often do. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Re: multiarch/bi-arch status (ETA) question
tony mancill <[EMAIL PROTECTED]> writes: > Matthias Julius wrote: >> Goswin von Brederlow <[EMAIL PROTECTED]> writes: >>>Better not try that with /usr/lib. :) >> >> Well, you always have a backup. Right? > > > > It's not the backup that'll kill you, it's having a dynamically linked > copy of "ln" that needs something in /usr/lib/ that'll drive you crazy. > Solaris used to have this problem (I forget how far back), where if you > dusted /usr you couldn't even run basic filesytem manipulation commands > without booting from rescue media. > > Put another way, are you 100% sure your restore program doesn't need > anything under /usr/? :) > > Absolutely as it runs of the backup dvd directly as a live filesytem. Anything else would be useless. :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Stephan Seitz <[EMAIL PROTECTED]> writes: > On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote: >>We are not saying you shouldn't make binaries coinstallable for >>multiple archs, we are only saying we won't make this a policy. It is >>left to each package maintainer to decide if he wants to make the >>multiarch change for his binary too or not and nearly every one will >>not. > > All right, this is a solution I can live with. Until now I thought, > that it would be impossible, even with multiarch, to install two > programs together. It is impossible to install two packages that contain the same filename. Libraries use /usr/lib/arch-os/ to make libs differ between archs. Doing the same for binaries is possible but also has drawbacks. Specifying "Multiarch: yes" for a binary means that packages depending on it will force the installation of the binary in the same ABI as the depending package. This is usualy not what one wants but it only wastes some disk space. Also programs don't depend on something like galeon (i hope). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[OT] Re: multiarch/bi-arch status (ETA) question
Matthias Julius wrote: > Goswin von Brederlow <[EMAIL PROTECTED]> writes: >>Better not try that with /usr/lib. :) > > Well, you always have a backup. Right? It's not the backup that'll kill you, it's having a dynamically linked copy of "ln" that needs something in /usr/lib/ that'll drive you crazy. Solaris used to have this problem (I forget how far back), where if you dusted /usr you couldn't even run basic filesytem manipulation commands without booting from rescue media. Put another way, are you 100% sure your restore program doesn't need anything under /usr/? :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote: We are not saying you shouldn't make binaries coinstallable for multiple archs, we are only saying we won't make this a policy. It is left to each package maintainer to decide if he wants to make the multiarch change for his binary too or not and nearly every one will not. All right, this is a solution I can live with. Until now I thought, that it would be impossible, even with multiarch, to install two programs together. The only binaries people wanted in 32/64 bit so far are all plugin using binaries where the plugins are only available in 32bit. A very small subset of all packages. You're right. Shade and sweet water! Stephan -- | Stephan SeitzE-Mail: [EMAIL PROTECTED] | | WWW: http://fsing.rootsland.net/~stse/| | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Better not try that with /usr/lib. :) Well, you always have a backup. Right? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
David Wood <[EMAIL PROTECTED]> writes: > On Wed, 6 Jul 2005, Hugo Mills wrote: > >> They're not (directly) the way that the Debian multiarch is most >> likely to go. Unfortunately, the relevant site seems to be down, but >> take a look at [1], and possibly some of the other (Google cached) >> files in [2]. > > Just out of curiosity; does anyone know what was wrong with the > way documented in: > > http://www.linuxbase.org/futures/ideas/multiarch/ Afaik that is completly based on and in sync with our multiarch proposal and exactly what we want to achive. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Stephan Seitz <[EMAIL PROTECTED]> writes: > On Wed, Jul 06, 2005 at 08:45:43AM -0400, Stephen Frost wrote: >>you've described. You havn't given any reason why a user would have any >>use for it. There are quite a few reasons why trying to do such would > > Hm, normally, I wouldn't need a firefox with flash plugin or a > mplayer/xine with old codecs, so I would use the 64bit version. But > sometimes I need flash, the realplayer or old video codecs. > Of course I could build a chroot, but then I wouldn't need multiarch. > > So why don't create /usr/bin/i386 and /usr/bin/amd64 and populate > /usr/bin with symlinks to the programs. You could build something like > update-alternative, so admins can switch between the 32bit and 64bit > version as default. > > Shade and sweet water! > > Stephan Because there are so very few plugin using programs that need that at all and changing 16K packages just so maybe 20 packages don't have to do something special is rather pointless. Feel free to change mplayer to use /usr/bin/i386 and /usr/bin/amd64 or use mplayer.i386 and mplayer.amd64 and an alternative for mplayer. The change is easy to make for packages that need it and realy useless for everything else. We are not saying you shouldn't make binaries coinstallable for multiple archs, we are only saying we won't make this a policy. It is left to each package maintainer to decide if he wants to make the multiarch change for his binary too or not and nearly every one will not. The only binaries people wanted in 32/64 bit so far are all plugin using binaries where the plugins are only available in 32bit. A very small subset of all packages. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, 6 Jul 2005, Goswin von Brederlow wrote: Mplayer can play all the common files in 64bit directly except the mov files of current movie trailers. Anything else mplayer needs w32codecs for are rather uncommon in my experience. I find 64-bit unplayable real, wmv and mov files to be by far the most common media I run across, but of course, it's not a scientific survey... But if you do need w32codecs then just stick with a 32bit mplayer. With multiarch that will be just "apt-get install mplayer-686 w32codecs". Till then it means a chroot or some manual fiddling. Quite right. Let alone for things like OO, which are a) essential, and b) involve complexities like "how do I print from chroot" (doh). All doable with chroot, but so inferior as to give multiarch real impetus, I would think. Also, at some point, windows will release w64codecs and someone will add support for it to mplayer. Getting sick of waiting for Microsoft and their captive developers to do things is maybe the biggest reason we are all here, yes? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
David Wood <[EMAIL PROTECTED]> writes: > On Wed, 6 Jul 2005, Goswin von Brederlow wrote: > >> Getting the toolchain adapted is more important than some trivial mv >> commands for libs. > > You're right, of course, but I don't understand why we should avoid > doing them. With the new dirs in place and linked from the old > locations, package conversion can start. Until then, the process waits > to start. Why wait? We shouldn't. We just have to test this very carefully or the fallout of a bad upload will create too much oposition to including multiarch patches and slow us down overall. Imaging the bad blood you would create if you break libc6. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
David Wood <[EMAIL PROTECTED]> writes: > On Wed, 6 Jul 2005, Goswin von Brederlow wrote: > >> Hmm, I use Acrobat Reader, Mplayer and a bit of Wine on my >> pure64. What problems do you have? > > The only important thing that distinguishes mplayer from all the other > video players is its ability to use win32 codecs, and thus be actually > useful in the real world. Does not work in pure64, except in > chroot. I'm not even saying multiarch would help solve this problem (I > don't know), just commenting generally. > > Wine: interesting. I'll (optimistically) take another look. Mplayer can play all the common files in 64bit directly except the mov files of current movie trailers. Anything else mplayer needs w32codecs for are rather uncommon in my experience. But if you do need w32codecs then just stick with a 32bit mplayer. With multiarch that will be just "apt-get install mplayer-686 w32codecs". Till then it means a chroot or some manual fiddling. Also, at some point, windows will release w64codecs and someone will add support for it to mplayer. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Matthias Julius <[EMAIL PROTECTED]> writes: > David Wood <[EMAIL PROTECTED]> writes: > >>> can't be a symlink to /usr/lib/i386-linux after all. So if programs on >> >> I don't understand. Why not? > > Just try it: > > - mkdir /usr/lib/i386-linux > - rm -r /usr/lib > - ln -s /usr/lib/i386-linux /usr/lib > > Does that work on your machine? > > Matthias Better not try that with /usr/lib. :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Stephen Frost <[EMAIL PROTECTED]> writes: > * Lennart Sorensen ([EMAIL PROTECTED]) wrote: >> On Tue, Jul 05, 2005 at 04:46:59PM -0400, Stephen Frost wrote: >> > What's the reason for having both versions of a given app installed? >> > I'm pretty sure it was decided that was a bad idea and that there wasn't >> > any good use case for it and so we weren't going to try and support it. >> > It just doesn't make sense. >> >> I want to play with 64bit firefox so i can develop a 64bit plugin for >> it. I might at the same time want 32bit firefox so I can use plugins >> that are still 32bit only. >> >> That's just one reason. Then you need a chroot or you have to alternate between having 64bit firefox and 32bit firefox installed. Thats just like alternating between having an developement firefox and the unstable one installed. If you relay think this will be such a common case then move the /usr/bin/firefox wraper script (it uses a wraper, right?) into a common arch:all package and call linux32 firefox or linux64 firefox to get a specific one (after adding uname checks to the wraper). The general feeling was that this situation is uncommon enough to burden the packagers of the few cases with solving it instead of some realy ugly and difficult hacks in dpkg or similar. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
[EMAIL PROTECTED] (Bob Proulx) writes:
> This is where it gets ugly. The /usr/share part overlaps between the
> two packages. As long as the md5sum of a file is the same rpm will
> allow packages to overlap files. (Personally I think that is a bad
> thing and should not have been designed that way.) I used zlib as a
> small clean example. Other packages have man pages shared in
> /usr/share too and the list goes on.
>
> This file overlap behavior is a base feature of rpm and predates
> biarch by a long time. Any two packages can share files if the md5sum
> matches. But remove one of the packages and that file is removed,
> leaving the other package in a broken state without that particular
> file. This has been a long standing behavior of rpm that is now
> exploited for use in biarch. Also that you can install multiple
> packages of the same name as long as no files with conflicting md5sums
> overlap between them. This has been used for a long time to install
> multiple versions of shared libraries with exactly the same package
> name.
That sounds like there is no special biarch support at all in rpm but
just the support to have multiple versions of a package installed and
incidentaly that can be used for this too. Lucky break for rpm I
guess.
This is quite similar to very early biarch proposals.
> These two biarch packages are almost but not quite required to be in
> lockstep. It is possible to upgrade one without the other as long as
> the shared files have the same md5sum. But since that rarely happens
> in practice it means that you must upgrade both at the same time on
> the same command line to rpm. Because if on the same command line
> then rpm will allow the upgrade, but not separately.
>
> What uses /usr/lib/libz.so.1, the 32-bit library? Nothing on the
> system. That is provided for 32-bit compatibility with other
> binaries. The system is otherwise fully 64-bit and will use the
> /usr/lib64/libz.so.1, the 64-bit library. This is equivalent, but
> different, to a 32-bit chroot on Debian because it has all of the
> files in individual packages as the actual 32-bit versions. This is
> not the same as ia32-libs which has all of the libs lumped into one
> monolithic library package. Of course the effect of being able to run
> 32-bit legacy programs in compatibility mode is the same.
>
> The native system is fully 64-bit in that all of the /bin and /usr/bin
> programs are 64-bit. The shell for #!/bin/sh for example is 64-bits.
> The /usr/bin/perl is 64-bit. And so on. I believe all executable
> binaries on PATH are 64-bit.
>
> The rpm program knows about architectures for dependencies. But
> packages are not always there. For example the ghostscript package
> depends upon 'libm.so.6()(64bit)' fine. But only depends upon 'zlib'
> and I believe if only the 32-bit version were installed it would meet
> the dependency of that particular package but of course not be
> sufficient to the needs of the 64-bit program. Of course this is
> simply a single package bug but illustrative.
Now that '(64bit)' is something they had to add for biarch support.
There was talk about doing the same for multiarch early on but it
breaks backwards compatibility, i.e. old packages that don't have the
(64bit) will break. We improved that by having libraries state
"Multiarch: yes" and have dpkg then match the arch of the lib and
depending package to see if thats enough.
> The rpm .spec file that builds the library packages (similar to
> debian/rules et al) is the same between 32-bit and 64-bit builds but
> produces different locations for the library files. This is done by
> using %{_libdir} as a macro in the spec file. That definition is
> changed to be /usr/lib on 32-bit compiles and /usr/lib64 on 64-bit
> compiles. So the same source builds two different packages. But on
> different hosts.
>
> These compilations take place on different machines because it depends
> on and uses the default build on that host. Otherwise the .spec file
> would need to be different and it is counted on to be the same so it
> must use the defaults on the different hosts. To the best of my
> knowledge it is not possible to build a normal 32-bit rpm package on a
> 64-bit host, unless using a 32-bit chroot which of course would work.
>
> Bob
That will (at first) be true for multiarch too. Using 'linux32 chroot
somewhere' will work but not just building on the host directly. I'm
not sure if anyone is thinking or working on creating support for
'cross' builds without the chroot. Doesn't seem usefull as all builds
should be done in chroots anyway.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Digesting about 8 things into a single response... On Wed, 6 Jul 2005, Goswin von Brederlow wrote: You only need dpkg support to utilize it. The design is such that the debs shall remain compatible to older debian. You just don't get the multiarch benefits. So apt/dpkg are not realy blocking issues to porting stuff. ... The plan is to add multiarch support step by step while having a single arch system right up to the moment everything is ready. And even after having single arch must be possible. People that want pure64 should never be forced to install 32bit cruft as well and vice versa. This is the heart of what I'm saying... And hence my questions so far. On Wed, 6 Jul 2005, Hugo Mills wrote: They're not (directly) the way that the Debian multiarch is most likely to go. Unfortunately, the relevant site seems to be down, but take a look at [1], and possibly some of the other (Google cached) files in [2]. Just out of curiosity; does anyone know what was wrong with the way documented in: http://www.linuxbase.org/futures/ideas/multiarch/ On Wed, 6 Jul 2005, Hugo Mills wrote: If I may venture a little further, the idea that all of this must be done in one giant atomic effort is apparently very popular... why? Because you can't demonstrate that your modified packages are actually going to work properly (and in fact, they won't, if you make only the modifications you propose) without having a working multiarch-aware packaging system to test them with. Sure you can. Just test them. It sounds like you want to maintain two sets of packages: one normal, one fixed for multiarch. Is that really easier than just making the links, updating your existing set of packages over time, and doing verification on a pre-release multiarch systems with increasing aggressiveness until a multiarch release? On Wed, 6 Jul 2005, Goswin von Brederlow wrote: Having the links can hide problems in other parts I would rather see crash and burn during build than 2 years from now when symlinks are removed. How are they hidden unless you are not looking? To test you just remove links, right? The benefit being with the links in place you can start migrating packages while continuing to use them. On Wed, 6 Jul 2005, Goswin von Brederlow wrote: That would look how? The only one symlink solution is '/usr/bin/i386 -> .' and changes nothing. I see what you mean, but I still don't understand. It changes something; I can then start to port existing packges, instead of having to keep two sets. On Wed, 6 Jul 2005, Lennart Sorensen wrote: You can't make a link to a child of yourself since then the child has no parent dir to beling to if the parent isn't a directory. it would work if you did this: /usr/lib -> /.crap/usr/lib/i386-linux Then the parent isn't /usr/lib and hence you can make /usr/lib whatever you want. Just doesn't seem that nice to me. Thank you (all) for the patient explanation. I knew there was something I wasn't getting. .crap would work; I agree it's not nice, but I'm thinking, your alternative is maintaining and transitioning to a whole alternative set of packages. Surely a solution that allows you to move the existing packages gradually is the lesser evil? But it doesn't work with: /usr/lib -> /usr/lib/i386-linux Since in that case you either have to create the directories /usr/lib/i386-linux at which point you can't make /usr/lib a symlink since there already exists a dir with that name, and if you create the symlink /usr/lib pointing to /usr/lib/i386-linux first (with the target obviously nonexistant) then you won't be able to make the directory since /usr/lib that it should go in doesn't point to a location that exists so you can't make a subdir in it. Something else ugly... Just curious, why would this break: mkdir /usr mkdir /usr/lib ln -s /usr/lib /usr/lib/i386-linux It's "recursive," but it appears functional... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, Jul 06, 2005 at 08:45:43AM -0400, Stephen Frost wrote: you've described. You havn't given any reason why a user would have any use for it. There are quite a few reasons why trying to do such would Hm, normally, I wouldn't need a firefox with flash plugin or a mplayer/xine with old codecs, so I would use the 64bit version. But sometimes I need flash, the realplayer or old video codecs. Of course I could build a chroot, but then I wouldn't need multiarch. So why don't create /usr/bin/i386 and /usr/bin/amd64 and populate /usr/bin with symlinks to the programs. You could build something like update-alternative, so admins can switch between the 32bit and 64bit version as default. Shade and sweet water! Stephan -- | Stephan SeitzE-Mail: [EMAIL PROTECTED] | | WWW: http://fsing.rootsland.net/~stse/| | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
El mié, 06-07-2005 a las 09:11 -0400, Matthias Julius escribió: > David Wood <[EMAIL PROTECTED]> writes: > > >> can't be a symlink to /usr/lib/i386-linux after all. So if programs on > > > > I don't understand. Why not? > > Just try it: > > - mkdir /usr/lib/i386-linux > - rm -r /usr/lib > Does that work on your machine? You're right, I got this far and now the following line won't work. > - ln -s /usr/lib/i386-linux /usr/lib :-) Greetings, -- Javier Kohen <[EMAIL PROTECTED]> ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: multiarch/bi-arch status (ETA) question
David Wood <[EMAIL PROTECTED]> writes: >> can't be a symlink to /usr/lib/i386-linux after all. So if programs on > > I don't understand. Why not? Just try it: - mkdir /usr/lib/i386-linux - rm -r /usr/lib - ln -s /usr/lib/i386-linux /usr/lib Does that work on your machine? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
El mié, 06-07-2005 a las 09:32 -0400, David Wood escribió: > On Wed, 6 Jul 2005, Goswin von Brederlow wrote: > > > Hmm, I use Acrobat Reader, Mplayer and a bit of Wine on my > > pure64. What problems do you have? > > The only important thing that distinguishes mplayer from all the other > video players is its ability to use win32 codecs, and thus be actually "From all the other video players.." save for gstreamer, xine, etc... Greetings, -- Javier Kohen <[EMAIL PROTECTED]> ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: multiarch/bi-arch status (ETA) question
On Wed, 6 Jul 2005, Goswin von Brederlow wrote: Getting the toolchain adapted is more important than some trivial mv commands for libs. You're right, of course, but I don't understand why we should avoid doing them. With the new dirs in place and linked from the old locations, package conversion can start. Until then, the process waits to start. Why wait? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Wed, 6 Jul 2005, Goswin von Brederlow wrote: Hmm, I use Acrobat Reader, Mplayer and a bit of Wine on my pure64. What problems do you have? The only important thing that distinguishes mplayer from all the other video players is its ability to use win32 codecs, and thus be actually useful in the real world. Does not work in pure64, except in chroot. I'm not even saying multiarch would help solve this problem (I don't know), just commenting generally. Wine: interesting. I'll (optimistically) take another look. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote: > On Tue, Jul 05, 2005 at 07:54:06PM -0400, Stephen Frost wrote: > > apt-get install A::amd64; > > Should automatically uninstall the i386 version of A and install the > > amd64 version. > > If that's how it is going to behave, I will stick with a chroot for > 32bit. Much more useful then. I do have reason to want both the 32 and > 64bit versions of a program. I think many people do, especially > developers but also users. Developers are unlikely to use the packaging system in the few cases you've described. You havn't given any reason why a user would have any use for it. There are quite a few reasons why trying to do such would be very, very ugly and would undoubtably cause problems for both users and developers. Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
On Tue, Jul 05, 2005 at 04:56:34PM -0400, David Wood wrote: > Why bother making it hard when you can just make it easy and link the > whole directory? You can't make a link to a child of yourself since then the child has no parent dir to beling to if the parent isn't a directory. it would work if you did this: /usr/lib -> /.crap/usr/lib/i386-linux Then the parent isn't /usr/lib and hence you can make /usr/lib whatever you want. Just doesn't seem that nice to me. But it doesn't work with: /usr/lib -> /usr/lib/i386-linux Since in that case you either have to create the directories /usr/lib/i386-linux at which point you can't make /usr/lib a symlink since there already exists a dir with that name, and if you create the symlink /usr/lib pointing to /usr/lib/i386-linux first (with the target obviously nonexistant) then you won't be able to make the directory since /usr/lib that it should go in doesn't point to a location that exists so you can't make a subdir in it. > I don't see a problem here. The case seems rare; when it happens the order > of the elements in PATH dictates preference, and aliases (or any other > mechanism) can be used to override. > > The common case is to deal with libraries for packages that aren't > available on both architectures anyway. But you need both versions of each library in case you have programs that only come for one or the other of the architectures that needs those libs. > This sounds like a good example of what work will be involved in reforming > packages to deal with the new standard. Probably you end up with those > share files in "common" noarch packages that are a dependency of the > arch-specific ones. In fact I think I've seen packages doing that already. That would work, but would require fixing some packages for sure. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote: > On Tue, Jul 05, 2005 at 04:46:59PM -0400, Stephen Frost wrote: > > What's the reason for having both versions of a given app installed? > > I'm pretty sure it was decided that was a bad idea and that there wasn't > > any good use case for it and so we weren't going to try and support it. > > It just doesn't make sense. > > I want to play with 64bit firefox so i can develop a 64bit plugin for > it. I might at the same time want 32bit firefox so I can use plugins > that are still 32bit only. > > That's just one reason. And a rather unlikely one at that. > Repeat for mplayer where some codecs are 32bit only for now, but others > might run much faster in 64bit and you want to help port it there. So you're going to have your own source code which you're going to be developing with and building. Sorry, I think you'll just have to manage on your own in this case (I mean, really, you're almost certainly going to be doing all of this outside of the existing packaging system *anyway*). I don't think it's sensible or useful to attempt to support having a 32bit and a 64bit version of a given app installed in the packaging system. Your example above doesn't even illustrate a reason to support it. > > This is only an issue with libraries, and /usr/share should have things > > which are arch-independent and /usr/lib/ should have > > arch-dependent things. If packages don't follow that today then they're > > broken already and need to be fixed. It is true that there can't be > > multiple things installed with files in the same place, so any > > /usr/share usage in libraries needs to be split out in a -common package > > for that library. This isn't an issue for programs because we're not > > interested in supporting the unjustified case for having the same > > program both 32bit and 64bit at the same time. > > If we don't then I consider multiarch very broken. That's nice. Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
On Tue, Jul 05, 2005 at 07:54:06PM -0400, Stephen Frost wrote: > apt-get install A::amd64; > Should automatically uninstall the i386 version of A and install the > amd64 version. If that's how it is going to behave, I will stick with a chroot for 32bit. Much more useful then. I do have reason to want both the 32 and 64bit versions of a program. I think many people do, especially developers but also users. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Tue, Jul 05, 2005 at 04:46:59PM -0400, Stephen Frost wrote: > What's the reason for having both versions of a given app installed? > I'm pretty sure it was decided that was a bad idea and that there wasn't > any good use case for it and so we weren't going to try and support it. > It just doesn't make sense. I want to play with 64bit firefox so i can develop a 64bit plugin for it. I might at the same time want 32bit firefox so I can use plugins that are still 32bit only. That's just one reason. Repeat for mplayer where some codecs are 32bit only for now, but others might run much faster in 64bit and you want to help port it there. > This is only an issue with libraries, and /usr/share should have things > which are arch-independent and /usr/lib/ should have > arch-dependent things. If packages don't follow that today then they're > broken already and need to be fixed. It is true that there can't be > multiple things installed with files in the same place, so any > /usr/share usage in libraries needs to be split out in a -common package > for that library. This isn't an issue for programs because we're not > interested in supporting the unjustified case for having the same > program both 32bit and 64bit at the same time. If we don't then I consider multiarch very broken. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Tue, Jul 05, 2005 at 04:40:17PM -0400, David Wood wrote: > But it is not incompatible unless you remove the links - and then you are > no longer following the proposal. > > As I understand it, /usr/lib is a symlink/hardlink/bindmount to > /usr/lib/i386-linux, not the other way around. If /usr/lib/i386-linux exists, then /usr/lib is a directory. hence /usr/lib can't be a symlink. The files in /usr/lib can symlink to /usr/lib/i386-linux if you want, but /usrlib itself can't be anything but a directory. > But they won't. I must have expressed myself quite badly to have been > misunderstood on this so much. > > I am not saying that one starts multiarch and immediately pretends its > finished. Only that one can start, without breaking anything... so why not > start? > > Why not make /usr/lib/i386-linux and make the links? New packages would > eventually follow the new standard directly; old ones would be gradually > ported over. The whole time, you are still pure64, or ia32. At some point, > when dpkg/apt and the other infrastructure work is finished, and a usable > subset of packages is compliant, then you can switch to "being" multiarch. > In the meantime, you manage everything just as you do now. > > Right. But that's why you make the links, and then start on the work. Well I think what multiarch needs is for someone to go try it and figure out all the kinks that have to be solved. Ofcourse not everyone will necesarily even want multiarch. > Later, when the work is complete, we can support multiple architectures, > and until then, we have lost nothing - everything works as it does now. You will at least loose a bunch of inodes, but I think we could survive that. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Tue, Jul 05, 2005 at 09:13:47PM -0400, David Wood wrote: > On Wed, 6 Jul 2005, Kurt Roeckx wrote: > > >There are not going to be any symlinks at all. There is no need > > So, the posted documents are not correct on this (basic, major) point? They're not (directly) the way that the Debian multiarch is most likely to go. Unfortunately, the relevant site seems to be down, but take a look at [1], and possibly some of the other (Google cached) files in [2]. > And why not have them? Obviously there is a need - to ease migration... > > If I may venture a little further, the idea that all of this must be done > in one giant atomic effort is apparently very popular... why? Because you can't demonstrate that your modified packages are actually going to work properly (and in fact, they won't, if you make only the modifications you propose) without having a working multiarch-aware packaging system to test them with. Hugo. [1] http://66.249.93.104/search?q=cache:eZ4_5t0ZWeoJ:raw.no/debian/amd64-multiarch-2+site:raw.no+multiarch&hl=en&client=firefox [2] http://www.google.co.uk/search?q=site%3Araw.no+multiarch&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox&rls=org.mozilla:en-US:unofficial -- === Hugo Mills: [EMAIL PROTECTED] carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- There's an infinite number of monkeys outside who want to --- talk to us about this new script for Hamlet they've worked out! signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
On 7/6/05, Bob Proulx <[EMAIL PROTECTED]> wrote: [RedHat x86_64] Thanks for your insight in the RedHat way. With already three OSes installed on my AMD64, I don't feel like trying another one (an Solaris 10 would be first anyway), but their approach is definitely relevant for us. Both as an example and as a "de facto" standard. > That listing lists both packages back to back. Each zlib package has > two parts. One is architecture dependent, the /usr/lib/lib*so* part. > The other is architecture independent, the /usr/share part. > > This is where it gets ugly. The /usr/share part overlaps between the > two packages. Correct. I remember Slackware did that, too, in the old days, and it is very ugly. The better way to do it is to have three (sub)packages: i386, x86_64 and shared. That is a bit like -common and -bin, but the packages differ only in architecture, not in the name. Imho that is the way to go. However, if you look closer, you find that both approaches impose the same restrictions: all two or three (sub)packages have to be exactly the same version, they have to match. So you can't upgrade one without upgrading the other(s). I think this severely limits the ability to install third-party i386 software on a RedHat x86_64 system. As soon as the third-party software requires a library upgrade, you get conflicts. (Now that problem isn't new either, it is the reason behind DLL hell...) > But remove one of the packages and that file is removed, > leaving the other package in a broken state without that particular > file. That is bizarre. Slackware could handle this case 11 (!) years ago. > These two biarch packages are almost but not quite required to be in > lockstep. It is possible to upgrade one without the other as long as > the shared files have the same md5sum. Hm... which probably equates to never :-) > This is equivalent, but > different, to a 32-bit chroot on Debian because it has all of the > files in individual packages as the actual 32-bit versions. A chroot solves the interlocking problem, at the expensive of a massive waste of disk space and cumbersome usability. I wonder whether it would be worth making a chroot more user friendly... Thomas
Re: multiarch/bi-arch status (ETA) question
Goswin von Brederlow wrote: > Adam Stiles writes: > > Most current "64 bit" Linux distributions are not pure 64-bit but > > contain both 32 and 64 bit libraries. In other words, they are > > multi-arch. Not multiarch but biarch. Not quite the same thing. > No. They have ia32-libs preinstalled. > > Multi-arch means the packaging system knows about the various archs > the system can run. Afaik no linux distribution can install the i386 > packages on amd64. They all have special 32bit amd64 packages for > stuff that needs it. That is not correct. On Red Hat for example if you have a 32-bit i686 rpm from a 32-bit system unmodified for amd64 you can install it on their amd64 system. RH allows you to install either 32-bit x86 or 64-bit amd64 rpm packages on the same system. You can mix and match them within the limits of the dependencies being fulfilled. See my previous post for details of how that is accomplished. > > This does not change the fact that it is a bodge. It is a bodge. Notably a useful one. Most users don't see it at the technical level. All they see is that they can install both legacy 32-bit and new 64-bit software on the same machine. They don't see the horrendous problem that allowing duplicated packages and overlapping packages cause. Bob signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
Goswin von Brederlow wrote: > Thomas Steffen writes: > > That is the theory, and I do believe in theory... until something more > > practical comes along. I use Openoffice, Acrobat Reader, Partimage, > > Mplayer, a bit of Wine, Oracle and sometimes Matlab for Linux. That > > makes seven applications that are not supported on pure-amd64. To the > > average user, running or not running seven applications is *way* more > > important than your theory. In fact, the average user is probably > > better off with a 32bit system, until he/she has 4 GB of memory. Agreed. > Hmm, I use Acrobat Reader, Mplayer and a bit of Wine on my > pure64. What problems do you have? The typical user considers flash in the web browser manditory. It is not DFSG free. The free software advocate will claim it evil, and it is, and will refuse to use it. But the typical user who doesn't really care about the politics will refuse to use any system that does not provide the fluff and glitter to which they have become adicted. I have set up those users in a 32-bit system so that they can run firefox along with all of the non-free plugins to which they are adicted. It is the lowest common denominator at the moment. Sad but true. But with a 64-bit subsystem we can still run our large memory cad tools on the same system. > >> 1) We don't care about anything that's not free software. (This is already > >> too much for most people, but let's say that's no problem...) > > > > Yep, that is the Debian stance. And Debian constantly redefines what > > counts as free software, which means you can suddenly be out in the > > rain. I could say some choice words here too. But really the extremests are driving all of the moderates out of Debian. In the end I think all of the moderates will be running Ubuntu. Bob signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
Goswin von Brederlow wrote:
> Bob Proulx writes:
> > Red Hat has implemented special case biarch support. Debian has not
> > implemented either but the goal is to implement multiarch.
>
> So under red hat you can actualy do: [whatever dpkg's -i is for rpm]
>
> rpm -i libfoo_i386.rpm
> rpm -i libfoo_amd64.rpm
> rpm -i bar_i386.rpm baz_amd64.rpm
>
> where bar and baz both need libfoo?
Correct. (Within the limits of the simplications.) That is exactly
how it works on Red Hat.
Here is a real example using zlib to make for concrete discussion. It
may be a little tedious for the casual reader. But perhaps there will
be use for these details for others.
rpm -q zlib
zlib-1.1.4-8.1
zlib-1.1.4-8.1
Two of them installed. They look the same. But we can query for more
information and see that they are actually different.
rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}-%{PLATFORM}\n" zlib
zlib-1.1.4-8.1-i386-redhat-linux-gnu
zlib-1.1.4-8.1-x86_64-redhat-linux-gnu
Let's list the files contained in the package.
rpm -ql zlib
/usr/lib/libz.so.1
/usr/lib/libz.so.1.1.4
/usr/share/doc/zlib-1.1.4
/usr/share/doc/zlib-1.1.4/README
/usr/lib64/libz.so.1
/usr/lib64/libz.so.1.1.4
/usr/share/doc/zlib-1.1.4
/usr/share/doc/zlib-1.1.4/README
That listing lists both packages back to back. Each zlib package has
two parts. One is architecture dependent, the /usr/lib/lib*so* part.
The other is architecture independent, the /usr/share part.
This is where it gets ugly. The /usr/share part overlaps between the
two packages. As long as the md5sum of a file is the same rpm will
allow packages to overlap files. (Personally I think that is a bad
thing and should not have been designed that way.) I used zlib as a
small clean example. Other packages have man pages shared in
/usr/share too and the list goes on.
This file overlap behavior is a base feature of rpm and predates
biarch by a long time. Any two packages can share files if the md5sum
matches. But remove one of the packages and that file is removed,
leaving the other package in a broken state without that particular
file. This has been a long standing behavior of rpm that is now
exploited for use in biarch. Also that you can install multiple
packages of the same name as long as no files with conflicting md5sums
overlap between them. This has been used for a long time to install
multiple versions of shared libraries with exactly the same package
name.
These two biarch packages are almost but not quite required to be in
lockstep. It is possible to upgrade one without the other as long as
the shared files have the same md5sum. But since that rarely happens
in practice it means that you must upgrade both at the same time on
the same command line to rpm. Because if on the same command line
then rpm will allow the upgrade, but not separately.
What uses /usr/lib/libz.so.1, the 32-bit library? Nothing on the
system. That is provided for 32-bit compatibility with other
binaries. The system is otherwise fully 64-bit and will use the
/usr/lib64/libz.so.1, the 64-bit library. This is equivalent, but
different, to a 32-bit chroot on Debian because it has all of the
files in individual packages as the actual 32-bit versions. This is
not the same as ia32-libs which has all of the libs lumped into one
monolithic library package. Of course the effect of being able to run
32-bit legacy programs in compatibility mode is the same.
The native system is fully 64-bit in that all of the /bin and /usr/bin
programs are 64-bit. The shell for #!/bin/sh for example is 64-bits.
The /usr/bin/perl is 64-bit. And so on. I believe all executable
binaries on PATH are 64-bit.
The rpm program knows about architectures for dependencies. But
packages are not always there. For example the ghostscript package
depends upon 'libm.so.6()(64bit)' fine. But only depends upon 'zlib'
and I believe if only the 32-bit version were installed it would meet
the dependency of that particular package but of course not be
sufficient to the needs of the 64-bit program. Of course this is
simply a single package bug but illustrative.
The rpm .spec file that builds the library packages (similar to
debian/rules et al) is the same between 32-bit and 64-bit builds but
produces different locations for the library files. This is done by
using %{_libdir} as a macro in the spec file. That definition is
changed to be /usr/lib on 32-bit compiles and /usr/lib64 on 64-bit
compiles. So the same source builds two different packages. But on
different hosts.
These compilations take place on different machines because it depends
on and uses the default build on that host. Otherwise the .spec file
would need to be different and it is counted on to be the same so it
must use the defaults on the different hosts. To the best of my
knowledge it is not possible to build a normal 32-bit rpm package on a
64-bit host, unless using a 32-bit chroot which of course would work.
Bob
si
Re: multiarch/bi-arch status (ETA) question
On Wed, 2005-07-06 at 03:27 +0200, Goswin von Brederlow wrote: > Ron Johnson <[EMAIL PROTECTED]> writes: > > > On Tue, 2005-07-05 at 13:36 -0400, David Wood wrote: > >> On Tue, 5 Jul 2005, Adam Stiles wrote: [snip] > >> > >> 2) We believe that C/C++ is usually magically portable across hardware > >> architectures. > > > > Well, you did say usually... > > > > Perfect example of non-portable C/C++ code: OOo. > > OOo is C, C++, asm, java, python, perl, ... and many more. Java *and* assembly. That's amusing, in a sick, sad, perverted manner. > > It's not in the debian-openoffice archives yet, but the latest > > message from this thread says that OOo2 might not ship 64-bit > > native. > > During the LinuxTag several people told me that tries on 64bit > just resulted in crashes, e.g. when opening any file. If only OOo had been written in Python & PyGTK... ;) -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. "It may not always be easy, convenient, or politically correct to stand for truth and right, but it is the right thing to do. Always." M. Russell Ballard signature.asc Description: This is a digitally signed message part
Re: multiarch/bi-arch status (ETA) question
David Wood <[EMAIL PROTECTED]> writes: > On Wed, 6 Jul 2005, Kurt Roeckx wrote: > >> There are not going to be any symlinks at all. There is no need > > So, the posted documents are not correct on this (basic, major) point? The only case symlinks are needed is binaries with rpath. Death to binaries with rpath. :) Having the links can hide problems in other parts I would rather see crash and burn during build than 2 years from now when symlinks are removed. > And why not have them? Obviously there is a need - to ease migration... > > If I may venture a little further, the idea that all of this must be > done in one giant atomic effort is apparently very popular... why? At best that is a misconception. Or a misunderstanding of the design. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Ron Johnson <[EMAIL PROTECTED]> writes:
> On Tue, 2005-07-05 at 13:36 -0400, David Wood wrote:
>> On Tue, 5 Jul 2005, Adam Stiles wrote:
>>
>> > Binary compatibility is irrelevant at best {every Linux machine already
>> > has a
>> > compiler installed} and harmful at worst {Windows has wide-scale binary
>> > compatibility -- and rampant malware}. All that matters is _source_
>> > compatibility: that the same source code will compile cleanly on a range
>> > of
>> > different architectures. Thanks to the excellent work done by the GNU
>> > project in developing their compiler suite and automated configuration /
>> > building tools, source compatibility is already a reality. And processors
>> > are fast enough now that there is no time saved in using precompiled
>> > binaries.
>>
>> I've heard this argument before. Maybe I misunderstand, but it seems to
>> amount to:
>>
>> 1) We don't care about anything that's not free software. (This is already
>> too much for most people, but let's say that's no problem...)
>>
>> 2) We believe that C/C++ is usually magically portable across hardware
>> architectures.
>
> Well, you did say usually...
>
> Perfect example of non-portable C/C++ code: OOo.
OOo is C, C++, asm, java, python, perl, ... and many more.
> It's not in the debian-openoffice archives yet, but the latest
> message from this thread says that OOo2 might not ship 64-bit
> native.
During the LinuxTag several people told me that tries on 64bit
just resulted in crashes, e.g. when opening any file.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
David Wood <[EMAIL PROTECTED]> writes: > On Tue, 5 Jul 2005, Thomas Steffen wrote: > >> The initiative has been taken by other distributions, and I don't see >> a viable alternative to follow their approach. That means /usr/lib for >> 32bit libs and /usr/lib64 for the 64bit libs. Yes, it is ugly, but it >> is close to inevitable. > > 1) We are not that compatible to begin with In what way? We follow LSB and such. >> I would prefer architecture neutral file positions very much >> (/usr/bin/i386 for binaries, /usr/lib/i386 for libraries etc), but I >> don't see how that can be "compatible" with RedHat/SuSUE. > > 2) A symlink? That would look how? The only one symlink solution is '/usr/bin/i386 -> .' and changes nothing. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Tue, 2005-07-05 at 13:36 -0400, David Wood wrote:
> On Tue, 5 Jul 2005, Adam Stiles wrote:
>
> > Binary compatibility is irrelevant at best {every Linux machine already
> > has a
> > compiler installed} and harmful at worst {Windows has wide-scale binary
> > compatibility -- and rampant malware}. All that matters is _source_
> > compatibility: that the same source code will compile cleanly on a range of
> > different architectures. Thanks to the excellent work done by the GNU
> > project in developing their compiler suite and automated configuration /
> > building tools, source compatibility is already a reality. And processors
> > are fast enough now that there is no time saved in using precompiled
> > binaries.
>
> I've heard this argument before. Maybe I misunderstand, but it seems to
> amount to:
>
> 1) We don't care about anything that's not free software. (This is already
> too much for most people, but let's say that's no problem...)
>
> 2) We believe that C/C++ is usually magically portable across hardware
> architectures.
Well, you did say usually...
Perfect example of non-portable C/C++ code: OOo.
It's not in the debian-openoffice archives yet, but the latest
message from this thread says that OOo2 might not ship 64-bit
native.
http://lists.debian.org/debian-openoffice/2005/07/msg00016.html
http://porting.openoffice.org/servlets/ReadMsg?list=dev&msgNo=15935
The King of the 3rd Gen languages from a portability standpoint is,
of course, COBOL. 30 year old code (even CICS stuff) will compile/run
directly on Linux with nary a change.
--
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.
"That doctrine of peace at any price has done more mischief than
any I can well recall that have been afloat in this country. It
has occasioned more wars than any of the most ruthless
conquerors. It has disturbed and nearly destroyed that political
equilibrium so necessary to the liberties and the welfare of the
world."
Benjamin Disraeli
signature.asc
Description: This is a digitally signed message part
Re: multiarch/bi-arch status (ETA) question
* Latchezar Dimitrov ([EMAIL PROTECTED]) wrote: > Do you really do dfs any time you want to do anything on your computer? Yeah, that's *exactly* the same thing as daring to use apt-get... Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
On Wed, 6 Jul 2005, Kurt Roeckx wrote: There are not going to be any symlinks at all. There is no need So, the posted documents are not correct on this (basic, major) point? And why not have them? Obviously there is a need - to ease migration... If I may venture a little further, the idea that all of this must be done in one giant atomic effort is apparently very popular... why? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: multiarch/bi-arch status (ETA) question
Do you really do dfs any time you want to do anything on your computer? Thanks, Latchezar > -Original Message- > From: Stephen Frost [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 05, 2005 7:54 PM > To: Latchezar Dimitrov > Cc: Lennart Sorensen; David Wood; Hugo Mills; Goswin von > Brederlow; debian-amd64@lists.debian.org > Subject: Re: multiarch/bi-arch status (ETA) question > > * Latchezar Dimitrov ([EMAIL PROTECTED]) wrote: > > > What's the reason for having both versions of a given app > installed? > > > I'm pretty sure it was decided that was a bad idea and that there > > > wasn't any good use case for it and so we weren't going > to try and > > > support it. > > > It just doesn't make sense. > > > > The only reason is to be able to run both of them at your > discretion. > > apt-get install A::amd64; > Should automatically uninstall the i386 version of A and install the > amd64 version. > > Thanks, > > Stephen >
Re: multiarch/bi-arch status (ETA) question
[EMAIL PROTECTED] (Lennart Sorensen) writes: > On Tue, Jul 05, 2005 at 04:25:39PM -0400, Stephen Frost wrote: >> Pfft, give me a break. Guess we'll never move anything ever again. >> That's just not how it works. > > No I am sure we will, we just won't claim it is a trivial change.A > > Starting to make a pile of symlinks without a plan certainly doesn't > seem productive. > >> Actually you can put a symlink in /usr/lib to the actual library in >> /usr/lib/i386-linux, if necessary. > > Per file yes. > >> That'd be why we need multiarch, yes. The symlinks can be used to solve >> the problem when you can be sure of the answer, and as I recall there >> was a proposal to have a 'default' for the system which would answer the >> question when there's multiple options on the system. > > Well I think the solution for multiarch will involve changes to how > ld-linux loads libraries and where it looks, although it could > potentially be managed just using ld.so.conf, although I don't think > that is necesarily the best place to handle it. Since each arch has it's own ld the default path just gets extended to include the new dir. Adding the dirs to ld.so.conf is a quick hack to simulate this behaviour but not the goal. > Of course there is also the issue of how to deal with calling the 32 or > 64bit version of program x if you have both versions installed. Perhaps > a helper tool to say run64bit version of x would deal with that, and > your idea of having symlinks in the original location to a default > version would deal well with that. If not specified you run the one > that has the symlink. Multiarch doesn't address this. Since programs are seens as doing the same jobs in 32bit or 64bit having both flavours is unneccesary. Couple that with the many many problems of moving /bin/* and /usr/bin/* anywhere else and you see why this is specificaly ignored. We know some users want mozilla 64bit and mozilla+flash 32bit installed in parallel. But I find that quite useless. Users that need flash just have to suffer a (slightly) slower 32bit mozilla for normal browsing too. The same can probably be said for most other cases where you would want 32bit and 64bit flavours of a program around. For the remaining cases, if any, the programs have to install as prog-x.i386-linux and prog-x.amd64-linux and set an alternative prog-x pointing on one of them. Or they install into /usr/lib/arch-os/prog-x/ and supply a wrapper in /usr/bin that picks one at runtime. Some solution that the package itself makes and not the packaging system in general. [The wraper could check uname and "linux32 progx-x" and "linux64 prog-x" would pick the right one then.] > Of course then there is things like data files in /usr/share which are > not architecture specific. If you install the same version of both 32 > and 64bit for a package, then the files should match and just keeping > one copy should be fine. If for some reason you install a different > version of one of them (as would happen during upgrades) how do we > resolve those files? They aren't always seperated into an architecture > all package (which would of course be trivial to handle). Do we divert > the files from the older version somewhere, and then remove it when the > older one is upgraded to match the newer one? No point wasting disk > space on identical files after all. Packages are strictly split into _arch and _all debs. Any shared files must be _all. There is also /usr/include for which most libs can share one tree for all archs. There is no packaging system magic planed here. This part is actualy the biggest chunk in porting to multiarch. >> You can certainly have a symlink from /usr/lib/libx.so.1 -> >> /usr/lib/i386-linux/libx.so.1, and if you have to pick one when there's >> multiple options available then you'll just have to pick one and that's >> life. Generally things that require this kind of hackery should be >> fixed regardless. > > Yes, but it does need fixing if anything is dependant on it. > Fortunately, we have the source code. > >> Depends on the 'default' setting of the box. > > That is reasonable. > > Len Sorensen The plan is to add multiarch support step by step while having a single arch system right up to the moment everything is ready. And even after having single arch must be possible. People that want pure64 should never be forced to install 32bit cruft as well and vice versa. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Tue, 5 Jul 2005, Thomas Steffen wrote: The initiative has been taken by other distributions, and I don't see a viable alternative to follow their approach. That means /usr/lib for 32bit libs and /usr/lib64 for the 64bit libs. Yes, it is ugly, but it is close to inevitable. 1) We are not that compatible to begin with I would prefer architecture neutral file positions very much (/usr/bin/i386 for binaries, /usr/lib/i386 for libraries etc), but I don't see how that can be "compatible" with RedHat/SuSUE. 2) A symlink? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
[EMAIL PROTECTED] (Lennart Sorensen) writes: > On Tue, Jul 05, 2005 at 03:04:56PM -0400, David Wood wrote: >> I don't understand. As far as I could see the problem you raised was what >> a (finished) multiarch solves. > > Multiarch was never finished as far as I know. > >> I keep saying it. There's a symlink. It's backwards-compatible! There is >> no package building involved to get started! >> >> If I have /usr/lib >> >> and suddenly it becomes a symlink to /usr/lib/i386-linux/ If you think about it that can't work. What can work is having ldconfig create the library symlinks in /usr/lib/i386-linux/ and /usr/lib/. You would have to choose one of i386 or amd64 as default to be linked into /usr/lib though. >> What's the problem? Yes, it will take work to _finish_, but why haven't we >> even _started_? > > Many packages/programs have hardcoded paths in them which will look in > /usr/lib and not in your new directory. That would be a policy violation already. RC bug. > Also not at all compatible with existing software on any architecture. > > Len Sorensen Only foreign software with needless rpaths might have problems with moved libs as Debian already requires this flexibility. The moved libs are also still standard conform as only the location of the LD is fixed. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Hugo Mills <[EMAIL PROTECTED]> writes: > On Tue, Jul 05, 2005 at 01:49:08PM -0400, David Wood wrote: >> Am I a bonehead or is it just a matter of moving some directories and >> symlinks around in etch and then the super-gradual process (many many >> years if you want) of migrating things from using the legacy symlinks to >> the multiarch dirs... Why wait to get started? What would break? > >It's quite a lot more complicated than that. You need explicit > support in dpkg, for a start. And in dselect, apt, and all apt's > friends. I had a go at doing the dpkg support last year, and it > defeated me(*). It is very much non-trivial. You only need dpkg support to utilize it. The design is such that the debs shall remain compatible to older debian. You just don't get the multiarch benefits. So apt/dpkg are not realy blocking issues to porting stuff. >Then you have to modify _every_ library package to build properly, > putting the files in the right places. This will probably involve at > least some work on the various Debian build systems. It won't all be > done by one person (or team of people), but by all the relevant > developers -- but that still causes a lot of work for the multiarch > developers in helping everyone else migrate. Small libraries are > probably easy, but (for example) libc and libstdc++ are very nasty to > get right. Not strictly true. You only need core libraries and then any lib that might be usefull to have. All of those can be done independent of each other and over a long time. A lot of the core libs have had patches for it already and it wasn't that much work to move the files around. >There are also (IIRC) big questions about handling things like perl > libraries and libs for other non-compiled (or bytecode-compiled) > languages, which remain unresolved. The only problem I'm aware of is plugin support. Their dependencies are reversed in respect to libraries and the dpkg/apt magic planed for multiarch won't work for them. For those the main packages have to provide a abi field. Perl already provides that for the abi version. Adding the arch is simple. But worst case anything with plugins won't be multiarch. You only ever need one perl or mozilla. Or not? >Hugo. > > (*) Probably not saying much -- I'm not the world's finest hacker -- > but I understand I'm not alone in finding dpkg's code really awkward > to work with. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
David Wood <[EMAIL PROTECTED]> writes: > On Tue, 5 Jul 2005, Goswin von Brederlow wrote: > >> But you don't realy gain anything by multiarch for amd64. Only 3 >> things come to my mind: OpenOffice, Flash support and w32codecs + >> 32bit mplayer. And only OO is in Debian. > > Maybe add wine to that list? (Disclaimer, haven't tried it lately) > > I actually have a completely different question. I just re-read the > multi-arch doc and two things jump out: first, it looks extremely > non-controvertial, i.e. all parties should at least agree it's simple > and right - there's nothing wrong with it; second, it looks there's no > reason to wait to start. > > Am I a bonehead or is it just a matter of moving some directories and > symlinks around in etch and then the super-gradual process (many many > years if you want) of migrating things from using the legacy symlinks > to the multiarch dirs... Why wait to get started? What would break? gcc, binutils, configure scripts, libtool. Gcc/Binutils have to search the multiarch paths before any lib with colliding includes can be packaged. Not sure if all core libs are free of this. Configure scripts have sometimes hardcoded paths to /usr/lib. Libtool adds rpath if libraries are not in default system paths and rpath means incompatibility to every other linux out there. And the amount of packages affected by those toolchain issues is basically everything. So it should not be just done in the hope nothing breaks. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
[EMAIL PROTECTED] (Bob Proulx) writes: > Thomas Steffen wrote: >> > Multiarch is something that goes way beyond what other >> > amd64 distributions have. >> >> Maybe, but the RedHat package management does support two different >> architectures, and it does it now. > > Technically that is "biarch". That is different than "multiarch". > Red Hat has implemented special case biarch support. Debian has not > implemented either but the goal is to implement multiarch. > > Using the language in the same way is important to avoid confusion. > > Bob So under red hat you can actualy do: [whatever dpkg's -i is for rpm] rpm -i libfoo_i386.rpm rpm -i libfoo_amd64.rpm rpm -i bar_i386.rpm baz_amd64.rpm where bar and baz both need libfoo? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Thomas Steffen <[EMAIL PROTECTED]> writes: > On 7/5/05, Stephen Frost <[EMAIL PROTECTED]> wrote: >> * Lennart Sorensen ([EMAIL PROTECTED]) wrote: >> > Many packages/programs have hardcoded paths in them which will look in >> > /usr/lib and not in your new directory. >> >> Then they're busted and need to be fixed. > > I guess you first have to explain how it do better. Assume you have > two glibc versions, one in 32bit and one in 64bit. They both need to > load locale plugins. The path is hard coded because there is not > really an alternative. Environment variables may not reflect the > process architecture. Configuration files just move the problem by one > level. And the PATH/LD_PATH does not contain the plugins, because they > should not be user visible. > > I have one or two ideas how this could be solved, but it is definately > not easy. > > Thomas Both libs have the path hardcoded to /usr/lib/-/. Where is the problem? The libc also needs to load nss modules. Same subdirs for those. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Paul Brook <[EMAIL PROTECTED]> writes: > On Tuesday 05 July 2005 19:46, David Wood wrote: >> On Tue, 5 Jul 2005, Hugo Mills wrote: >> >> I guess I can only ask... what... on... earth... was the problem? >> > >> > See below... >> >> Actually, I don't see where you've said what was objectionable about >> multiarch. >> >> > Well, let's say you want to install a 32-bit xine. That's written >> > in C, so you have to have a 32-bit glibc. So, you use dpkg to install >> > the 32-bit version of glibc2. But... you can't, because you already >> > *have* a package called glibc2 installed, which is the 64-bit version. >> >> No, you misunderstand. I don't expect that to work. It's obvious that if >> you just made the directory structure switch you still have a long way to >> go before you can install two different glibc packages. I'm just saying, >> why not make the directory structure switch and then _start_ doing the >> work of adding support to the package system/packages. Then, as I said: > > Until you have a coherent and generally acceptable plan for how to handle the > hard bits is there any point doing anything (other than as proof-of-concept)? > If you start migrating things before the long-term strategy has been agreed > you risk having to do another migration because you got it wrong. > > Paul We already have (had) a proof of concept. We have a lot of patches too. The only thing missing is the fine detail and cruciating testing by tons of users. I think the best next step is to get gcc and binutils support for multiarch added and tested. It seems the multilib stuff is currently broken again so it might be a good time to fix it the right way[tm]. Getting the toolchain adapted is more important than some trivial mv commands for libs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
* J?r?me Warnier ([EMAIL PROTECTED]) wrote: > [..] > As a start, does anyone know exactly how Solaris does, and can explain > it to whoever is interested in learning about multiarch? Wouldn't that > be interesting? It's basically biarch... I've got a couple Solaris boxes and I havn't seen much different between what it does and biarch. ie: Not what we're going for *anyway*, so... Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
Thomas Steffen <[EMAIL PROTECTED]> writes: > The initiative has been taken by other distributions, and I don't see > a viable alternative to follow their approach. That means /usr/lib for > 32bit libs and /usr/lib64 for the 64bit libs. Yes, it is ugly, but it > is close to inevitable. It is already obsoleted by recent drafts of the standards. They go the multiarch way too. > I would prefer architecture neutral file positions very much > (/usr/bin/i386 for binaries, /usr/lib/i386 for libraries etc), but I > don't see how that can be "compatible" with RedHat/SuSUE. Moving bin breaks tons of stuff while moving lib is, with the exception of already broken by design rpath, acomplished by simply adapting ld.so.conf. That's why /usr/lib/i386-linux/ is so "trivial" and /usr/bin/i386-linux/ is impossible. > But maybe we are taking the wrong approach, and a little bit of path > magic in ld.so/dlopen would solve the problem? Only for libs and we already do that. For binaries there are tons of scripts with #!/bin/sh [or any other interpreter] All of those would break if you start moving bin around. > Thomas MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Thomas Steffen <[EMAIL PROTECTED]> writes:
> On 7/5/05, David Wood <[EMAIL PROTECTED]> wrote:
>> On Tue, 5 Jul 2005, Adam Stiles wrote:
>>
>> > Binary compatibility is irrelevant at best {every Linux machine already
>> > has a
>> > compiler installed} and harmful at worst {Windows has wide-scale binary
>> > compatibility -- and rampant malware}.
>
> That is the theory, and I do believe in theory... until something more
> practical comes along. I use Openoffice, Acrobat Reader, Partimage,
> Mplayer, a bit of Wine, Oracle and sometimes Matlab for Linux. That
> makes seven applications that are not supported on pure-amd64. To the
> average user, running or not running seven applications is *way* more
> important than your theory. In fact, the average user is probably
> better off with a 32bit system, until he/she has 4 GB of memory.
Hmm, I use Acrobat Reader, Mplayer and a bit of Wine on my
pure64. What problems do you have?
>> 1) We don't care about anything that's not free software. (This is already
>> too much for most people, but let's say that's no problem...)
>
> Yep, that is the Debian stance. And Debian constantly redefines what
> counts as free software, which means you can suddenly be out in the
> rain.
>
>> 2) We believe that C/C++ is usually magically portable across hardware
>> architectures.
>
> As programmer I have to say that it should be, if you apply the due
> care. However, it will never really work unless you actually test and
> debug it. BTW, gcc/gdb does not properly support 64bit on SPARC, just
> as a side note on "magically portable".
Not magically, but properly written it does. Writing portable code is
an artform less and less people seem to perform nowadays.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Gnu-Raiz <[EMAIL PROTECTED]> writes: > I agree, if source software is unable to be compiled with 64 > bit support then I would suggest that the developer needs to > get with it. Just look at the hardware that is in the > channel, most 32 bit cpu's are getting phased out, yes you > can still get them but soon it will cost more, and have less > value then just getting a 64 bit cpu, motherboard. Intel, > AMD will all have 64 bit cpu's through all their channels in > a matter of months, this includes Celron, Sempron these will > be 64 bit cpu's. By the time etch is out, I would not be > surprised that most I386 code will be the exception not the > rule, in fact I suspect that it will be somewhat like > support for I386 was, ie you will have to compile in the > special options for 32 bit code in most distro's. Too me > multi-arch was a good idea a few years ago, but do you > really want a mixed bag in say 12-24 months when everything > is 64 bit anyway? You are totaly forgeting sparc64, ppc64, mips64, mipsel64 and s390x. Also you are forgetting linux/bsd multiarch systems. While for amd64 32bit code is hardly any use mixing bsd and linux might still be valuable. And for all other archs having the main system in 32bit mode is a huge gain in spead and resources while a few things gain from the larger address space of 64bit support (e.g. postgresql). I agree that multiarch isn't the holy grail for amd64 but a huge benefit to those other archs. > I also look at this as a good time for a source purge, those > developers who refuse to support, or update their code > should be left behind. The code that is not supported, or > lacks developers likewise should be left behind, or if its > important then they should work on a port. All one has to do > is look at the orphaned code in debian, how much of this > stuff would people actually miss if it was dropped, if it is > important than the developers can support it. What this > shows me is that developers don't care one way or the other, > and if that is the case then they deserve to be left behind. The code that makes problems isn't the year old unix hardened code without any upstream anymore but all those new fancy things with incapable programmers. Code quality has become much worse with i386 linux getting such a majority of programmers. > As far as apt and dpkg is concerned sure the idea of fixing > them for support sounds good, but is it necessary? I think > that the developers of these packages should consider the > marketplace in say 12-24 months see just where their > developer time should be spent. I would rather see, better > code, bug fixes, and overall stability then a fix for > something that is getting phased out. Yes it is worth it. Not because software won't compile 64bit (because it does as other 64bit archs and pure64 shows) but because users don't want it all 64bit. The inability of some people to write clean architecture independant code was never an argument for multiarch imho. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
[..] As a start, does anyone know exactly how Solaris does, and can explain it to whoever is interested in learning about multiarch? Wouldn't that be interesting? > Stephen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
Adam Stiles <[EMAIL PROTECTED]> writes: > On Tuesday 05 July 2005 15:44, Goswin von Brederlow wrote: >> All current linux distributions are pure64. They only differ slightly >> in the amount of 32bit libs preinstalled (what debian has as >> ia32-libs). Multiarch is something that goes way beyond what other >> amd64 distributions have. >> >> Multiarch standardizes and greatly simplifies installing random 32bit >> packages on amd64 by making the packaging system aware of the fact. It >> does not change the ability to run 32bit apps on amd64 at all, you > > Most current "64 bit" Linux distributions are not pure 64-bit but > contain both 32 and 64 bit libraries. In other words, they are > multi-arch. No. They have ia32-libs preinstalled. Multi-arch means the packaging system knows about the various archs the system can run. Afaik no linux distribution can install the i386 packages on amd64. They all have special 32bit amd64 packages for stuff that needs it. > This does not change the fact that it is a bodge. > > I am running a pure 64 bit Debian system. The kernel, libraries and > userland are all compiled as 64-bit software, and that's the way it > should be. Legacy 32-bit software is *always* going to hold you > back. Whatever you want to get working, just re-compile it in > 64-bit mode -- it's as simple as make clean, ./configure, make, su, > make install. You compiled your own kernel without 32bit syscall emulation? Then neither lilo nor grub will work anymore nor will syslinux or debian-cd and several other things. gcc probably doesn't even compile out of the box without that emulation layer. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
* Latchezar Dimitrov ([EMAIL PROTECTED]) wrote: > > What's the reason for having both versions of a given app installed? > > I'm pretty sure it was decided that was a bad idea and that > > there wasn't any good use case for it and so we weren't going > > to try and support it. > > It just doesn't make sense. > > The only reason is to be able to run both of them at your discretion. apt-get install A::amd64; Should automatically uninstall the i386 version of A and install the amd64 version. Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
Thomas Steffen wrote: > > Multiarch is something that goes way beyond what other > > amd64 distributions have. > > Maybe, but the RedHat package management does support two different > architectures, and it does it now. Technically that is "biarch". That is different than "multiarch". Red Hat has implemented special case biarch support. Debian has not implemented either but the goal is to implement multiarch. Using the language in the same way is important to avoid confusion. Bob signature.asc Description: Digital signature
RE: multiarch/bi-arch status (ETA) question
> -Original Message- > From: Stephen Frost [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 05, 2005 4:47 PM > To: Lennart Sorensen > Cc: David Wood; Hugo Mills; Goswin von Brederlow; > debian-amd64@lists.debian.org > Subject: Re: multiarch/bi-arch status (ETA) question > > * Lennart Sorensen ([EMAIL PROTECTED]) wrote: > > Of course there is also the issue of how to deal with > calling the 32 > > or 64bit version of program x if you have both versions installed. > > Perhaps a helper tool to say run64bit version of x would deal with > > that, and your idea of having symlinks in the original > location to a > > default version would deal well with that. If not > specified you run > > the one that has the symlink. > > What's the reason for having both versions of a given app installed? > I'm pretty sure it was decided that was a bad idea and that > there wasn't any good use case for it and so we weren't going > to try and support it. > It just doesn't make sense. The only reason is to be able to run both of them at your discretion. > > > Of course then there is things like data files in > /usr/share which are > > not architecture specific. If you install the same version > of both 32 > > and 64bit for a package, then the files should match and > just keeping > > one copy should be fine. If for some reason you install a > different > > version of one of them (as would happen during upgrades) how do we > > resolve those files? They aren't always seperated into an > > architecture all package (which would of course be trivial > to handle). > > Do we divert the files from the older version somewhere, and then > > remove it when the older one is upgraded to match the newer > one? No > > point wasting disk space on identical files after all. > > This is only an issue with libraries, and /usr/share should > have things which are arch-independent and /usr/lib/ > should have arch-dependent things. If packages don't follow > that today then they're broken already and need to be fixed. > It is true that there can't be multiple things installed with > files in the same place, so any /usr/share usage in libraries > needs to be split out in a -common package for that library. > This isn't an issue for programs because we're not interested > in supporting the unjustified case for having the same > program both 32bit and 64bit at the same time. > > Thanks, > > Stephen >
Re: multiarch/bi-arch status (ETA) question
On Tue, Jul 05, 2005 at 04:40:17PM -0400, David Wood wrote: > On Tue, 5 Jul 2005, Lennart Sorensen wrote: > > >The main objection is to change locations of files in a way that is > >incompatible with existing software on linux. > > But it is not incompatible unless you remove the links - and then you are > no longer following the proposal. > > >>Would they not work properly with the symlink in place? > > > >is /usr/lib/i386-linux a symlink back to /usr/lib or what? /usr/lib > > As I understand it, /usr/lib is a symlink/hardlink/bindmount to > /usr/lib/i386-linux, not the other way around. There are not going to be any symlinks at all. There is no need to have a symlink. The only case you might need a symlink is when it's using rpath's (or simular hardcoded paths), and nothing should be rpath's for something that isn't a private lib. Tools like lintian even check for this. All that needs to happen is that the libs get moved to an other dir. This of course requires that we have the tools to put them in the right dir and that they can be co-installed. And that dependencies work properly and things like that. This is being worked on. PS: For those going to debconf, Tollef is going to give a session about multi-arch, I suggest you visit it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On 7/5/05, David Wood <[EMAIL PROTECTED]> wrote: > It took a startlingly small amount of effort in the kernel. Not sure about small, but it works very well. Yes, if only userspace was just as easy... > If we were starting from a blank slate, we can have the rest > with a tiny change in our naming scheme, a bit of package metadata, and > some trivial code enhancements. Agreed. > If the sticking point is that it will take > some effort to enhance our _existing_ packages/package system, hey, we > have this excellent migration plan that doesn't commit us to anything, and > allows us to work on the new system while the old one works fine... However, we do not start with a blank slate. Rather, people expect that "Linux programs" also work on Debian. And since AMD64 is touted as a "compatible" improvement, of course they expect full compatibility. The initiative has been taken by other distributions, and I don't see a viable alternative to follow their approach. That means /usr/lib for 32bit libs and /usr/lib64 for the 64bit libs. Yes, it is ugly, but it is close to inevitable. I would prefer architecture neutral file positions very much (/usr/bin/i386 for binaries, /usr/lib/i386 for libraries etc), but I don't see how that can be "compatible" with RedHat/SuSUE. But maybe we are taking the wrong approach, and a little bit of path magic in ld.so/dlopen would solve the problem? Thomas
Re: multiarch/bi-arch status (ETA) question
On 7/5/05, Stephen Frost <[EMAIL PROTECTED]> wrote: > * Lennart Sorensen ([EMAIL PROTECTED]) wrote: > > Many packages/programs have hardcoded paths in them which will look in > > /usr/lib and not in your new directory. > > Then they're busted and need to be fixed. I guess you first have to explain how it do better. Assume you have two glibc versions, one in 32bit and one in 64bit. They both need to load locale plugins. The path is hard coded because there is not really an alternative. Environment variables may not reflect the process architecture. Configuration files just move the problem by one level. And the PATH/LD_PATH does not contain the plugins, because they should not be user visible. I have one or two ideas how this could be solved, but it is definately not easy. Thomas
Re: multiarch/bi-arch status (ETA) question
On Tue, 5 Jul 2005, Lennart Sorensen wrote: No I am sure we will, we just won't claim it is a trivial change.A It looks trivial to make the new directories and links and _start_. No such claims about the rest. :) Starting to make a pile of symlinks without a plan certainly doesn't seem productive. It seems like there's a good plan already documented. I'm still trying to find any objections to it that make sense; any at all, in fact... Actually you can put a symlink in /usr/lib to the actual library in /usr/lib/i386-linux, if necessary. Per file yes. Why bother making it hard when you can just make it easy and link the whole directory? Of course there is also the issue of how to deal with calling the 32 or 64bit version of program x if you have both versions installed. Perhaps a helper tool to say run64bit version of x would deal with that, and your idea of having symlinks in the original location to a default version would deal well with that. If not specified you run the one that has the symlink. I don't see a problem here. The case seems rare; when it happens the order of the elements in PATH dictates preference, and aliases (or any other mechanism) can be used to override. The common case is to deal with libraries for packages that aren't available on both architectures anyway. Of course then there is things like data files in /usr/share which are not architecture specific. If you install the same version of both 32 This sounds like a good example of what work will be involved in reforming packages to deal with the new standard. Probably you end up with those share files in "common" noarch packages that are a dependency of the arch-specific ones. In fact I think I've seen packages doing that already. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
* David Wood ([EMAIL PROTECTED]) wrote: > On Tue, 5 Jul 2005, Lennart Sorensen wrote: > >>Would they not work properly with the symlink in place? > > > >is /usr/lib/i386-linux a symlink back to /usr/lib or what? /usr/lib > > As I understand it, /usr/lib is a symlink/hardlink/bindmount to > /usr/lib/i386-linux, not the other way around. I'd like to see that symlink. :) > I am not saying that one starts multiarch and immediately pretends its > finished. Only that one can start, without breaking anything... so why not > start? This is true and I think we do need to start on it soon. I'm not sure about not breaking *anything*, but what does get broken needs to get fixed anyway. > Why not make /usr/lib/i386-linux and make the links? New packages would > eventually follow the new standard directly; old ones would be gradually > ported over. The whole time, you are still pure64, or ia32. At some point, > when dpkg/apt and the other infrastructure work is finished, and a usable > subset of packages is compliant, then you can switch to "being" multiarch. > In the meantime, you manage everything just as you do now. It'd probably be better to get multiarch support in the base packages first, but, eh. > Right. But that's why you make the links, and then start on the work. > > Later, when the work is complete, we can support multiple architectures, > and until then, we have lost nothing - everything works as it does now. Eh, I'd rather try to do without the symlinks to start and then see what breaks. :) Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote: > Of course there is also the issue of how to deal with calling the 32 or > 64bit version of program x if you have both versions installed. Perhaps > a helper tool to say run64bit version of x would deal with that, and > your idea of having symlinks in the original location to a default > version would deal well with that. If not specified you run the one > that has the symlink. What's the reason for having both versions of a given app installed? I'm pretty sure it was decided that was a bad idea and that there wasn't any good use case for it and so we weren't going to try and support it. It just doesn't make sense. > Of course then there is things like data files in /usr/share which are > not architecture specific. If you install the same version of both 32 > and 64bit for a package, then the files should match and just keeping > one copy should be fine. If for some reason you install a different > version of one of them (as would happen during upgrades) how do we > resolve those files? They aren't always seperated into an architecture > all package (which would of course be trivial to handle). Do we divert > the files from the older version somewhere, and then remove it when the > older one is upgraded to match the newer one? No point wasting disk > space on identical files after all. This is only an issue with libraries, and /usr/share should have things which are arch-independent and /usr/lib/ should have arch-dependent things. If packages don't follow that today then they're broken already and need to be fixed. It is true that there can't be multiple things installed with files in the same place, so any /usr/share usage in libraries needs to be split out in a -common package for that library. This isn't an issue for programs because we're not interested in supporting the unjustified case for having the same program both 32bit and 64bit at the same time. Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
On Tue, 5 Jul 2005, Lennart Sorensen wrote: The main objection is to change locations of files in a way that is incompatible with existing software on linux. But it is not incompatible unless you remove the links - and then you are no longer following the proposal. Would they not work properly with the symlink in place? is /usr/lib/i386-linux a symlink back to /usr/lib or what? /usr/lib As I understand it, /usr/lib is a symlink/hardlink/bindmount to /usr/lib/i386-linux, not the other way around. can't be a symlink to /usr/lib/i386-linux after all. So if programs on I don't understand. Why not? i386 look for things in /usr/lib and programs on amd64 look in /usr/lib, which one gets to keep the location and which one MUST move? But they won't. I must have expressed myself quite badly to have been misunderstood on this so much. I am not saying that one starts multiarch and immediately pretends its finished. Only that one can start, without breaking anything... so why not start? Why not make /usr/lib/i386-linux and make the links? New packages would eventually follow the new standard directly; old ones would be gradually ported over. The whole time, you are still pure64, or ia32. At some point, when dpkg/apt and the other infrastructure work is finished, and a usable subset of packages is compliant, then you can switch to "being" multiarch. In the meantime, you manage everything just as you do now. The problem is you have multiple architectures that all want the same filenames in the same location. bind mounts and symlinks won't solve that unfortunately. Changing the ld loader might, but even then anything else that has a hardcoded path needs fixing. Right. But that's why you make the links, and then start on the work. Later, when the work is complete, we can support multiple architectures, and until then, we have lost nothing - everything works as it does now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
On Tue, Jul 05, 2005 at 04:25:39PM -0400, Stephen Frost wrote: > Pfft, give me a break. Guess we'll never move anything ever again. > That's just not how it works. No I am sure we will, we just won't claim it is a trivial change.A Starting to make a pile of symlinks without a plan certainly doesn't seem productive. > Actually you can put a symlink in /usr/lib to the actual library in > /usr/lib/i386-linux, if necessary. Per file yes. > That'd be why we need multiarch, yes. The symlinks can be used to solve > the problem when you can be sure of the answer, and as I recall there > was a proposal to have a 'default' for the system which would answer the > question when there's multiple options on the system. Well I think the solution for multiarch will involve changes to how ld-linux loads libraries and where it looks, although it could potentially be managed just using ld.so.conf, although I don't think that is necesarily the best place to handle it. Of course there is also the issue of how to deal with calling the 32 or 64bit version of program x if you have both versions installed. Perhaps a helper tool to say run64bit version of x would deal with that, and your idea of having symlinks in the original location to a default version would deal well with that. If not specified you run the one that has the symlink. Of course then there is things like data files in /usr/share which are not architecture specific. If you install the same version of both 32 and 64bit for a package, then the files should match and just keeping one copy should be fine. If for some reason you install a different version of one of them (as would happen during upgrades) how do we resolve those files? They aren't always seperated into an architecture all package (which would of course be trivial to handle). Do we divert the files from the older version somewhere, and then remove it when the older one is upgraded to match the newer one? No point wasting disk space on identical files after all. > You can certainly have a symlink from /usr/lib/libx.so.1 -> > /usr/lib/i386-linux/libx.so.1, and if you have to pick one when there's > multiple options available then you'll just have to pick one and that's > life. Generally things that require this kind of hackery should be > fixed regardless. Yes, but it does need fixing if anything is dependant on it. Fortunately, we have the source code. > Depends on the 'default' setting of the box. That is reasonable. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote: > On Tue, Jul 05, 2005 at 03:21:41PM -0400, David Wood wrote: > > I'm just trying to understand what people's objections to multiarch are. I > > didn't understand what Hugo said in answer to that. I meant that it > > sounded like his answers (the problems he brought up) were things that > > multiarch would fix, not problems with multiarch itself. > > The main objection is to change locations of files in a way that is > incompatible with existing software on linux. Pfft, give me a break. Guess we'll never move anything ever again. That's just not how it works. > > Would they not work properly with the symlink in place? > > is /usr/lib/i386-linux a symlink back to /usr/lib or what? /usr/lib > can't be a symlink to /usr/lib/i386-linux after all. So if programs on > i386 look for things in /usr/lib and programs on amd64 look in /usr/lib, > which one gets to keep the location and which one MUST move? Actually you can put a symlink in /usr/lib to the actual library in /usr/lib/i386-linux, if necessary. > Sure you can recode ld-linux.so to look in /lib/ and > /usr/lib/ which I have seen done years ago on solaris systems > using various path lookup tricks and such. 'tricks' isn't exactly an appropriate word for this given that's how things are looked up today. > > And if that failed (is this really possible?), why not use a bind mount? > > Or a hard link? (Well, maybe you don't like hard links, but without > > multiarch, bind mounts in chroots are a fact of life anyway.) > > The problem is you have multiple architectures that all want the same > filenames in the same location. bind mounts and symlinks won't solve > that unfortunately. Changing the ld loader might, but even then > anything else that has a hardcoded path needs fixing. That'd be why we need multiarch, yes. The symlinks can be used to solve the problem when you can be sure of the answer, and as I recall there was a proposal to have a 'default' for the system which would answer the question when there's multiple options on the system. > > I feel a little crazy here. Is there something really basic I'm missing? > > > > What do you mean not compatible? With the linkage of the legacy directory > > to the new one, where would the incompatibility come from? > > Both amd64 and i386 programs want the legacy location. They can't both > be symlinks. And if you place the arch stuff as a subdir of the > original location it can't be a bind mount or symlink at all. You can certainly have a symlink from /usr/lib/libx.so.1 -> /usr/lib/i386-linux/libx.so.1, and if you have to pick one when there's multiple options available then you'll just have to pick one and that's life. Generally things that require this kind of hackery should be fixed regardless. > > A library would work unmodified in the old location, and then over time it > > can be modified to work in the new one. > > But is the old location file going to be i386 or amd64 architecture? Depends on the 'default' setting of the box. > Some other distributions have made their amd64 stuff use /usr/lib64/ > instead, which we are compatible with using a symlink, but it's > considered a rather unclean solution by many. Right, which is why there's multiarch... Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
On Tue, 5 Jul 2005, Thomas Steffen wrote: As programmer I have to say that it should be, if you apply the due care. However, it will never really work unless you actually test and debug it. BTW, gcc/gdb does not properly support 64bit on SPARC, just as a side note on "magically portable". Magically" may even have been a stronger word than I needed to make the point. "Easily" works just as well. Software that does not compile on 32bit is conceptually broken, and it I think you meant 64 bit? Therefore commercial closed software has a completely different compromise for binary compatibility than open source software. Open source software trades binary compatibility for conceptual clarity and easier development. So not requiring binary compatibility can buy us advantages, but it is not in itself a good thing. A very nuanced, interesting point. But... It took a startlingly small amount of effort in the kernel. So, the userspace... If we were starting from a blank slate, we can have the rest with a tiny change in our naming scheme, a bit of package metadata, and some trivial code enhancements. If the sticking point is that it will take some effort to enhance our _existing_ packages/package system, hey, we have this excellent migration plan that doesn't commit us to anything, and allows us to work on the new system while the old one works fine... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote: > On Tue, Jul 05, 2005 at 03:04:56PM -0400, David Wood wrote: > > What's the problem? Yes, it will take work to _finish_, but why haven't we > > even _started_? > > Many packages/programs have hardcoded paths in them which will look in > /usr/lib and not in your new directory. Then they're busted and need to be fixed. > Also not at all compatible with existing software on any architecture. This is just plain false. Thanks, Stephen signature.asc Description: Digital signature
