Re: multiarch status update
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Thu, May 18, 2006 at 04:52:58PM +0200, Goswin von Brederlow wrote: >> Wouter Verhelst <[EMAIL PROTECTED]> writes: >> >> > On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote: >> >> Wouter Verhelst <[EMAIL PROTECTED]> writes: >> >> > Have you considered employing the alternatives system (or something >> >> > similar)? What I'm suggesting is that you'd basically get a /bin64 and a >> >> > /bin32, where binaries install themselves in /bin by default but divert >> >> > to the /binXX when both versions are installed, and use symlinks in an >> >> > update-alternatives way to select the default. >> >> >> >> Each package that deems it neccessary can choose to do so. >> > >> > That's not what I meant, really. >> > >> >> I imagine the count to be near 0. Certainly nothing dpkg should handle >> >> automagicaly for all debs. >> > >> > Why not? >> >> Extra complexity with extra risk of breaking for no practical gain. > > That could technically be said about all of multiarch... I see a big gain in having a 32bit OOo for amd64 or being able to run any of the old 32bit software. I see no gain in having both a 32bit and 64bit make for example. >> Also don't forget that you can have more than 2 archs but dpkg can't >> have more than 2 diversions. > > Err, okay. I guess I shouldn't have mentioned "alternatives", because > that clearly confused you. The alternative is not the problem. The diversion is. > What I meant to say is that you could have dpkg set up things so that if > multiarch is in effect, files would be installed in /multiarch/i386/bin > rather than in /bin (or some such), and that symlinks would be made to > /bin so that the entire process would be transparent to a package. > Alternatively, you could also set it up so that files would be installed > in /bin by default, but then moved to /multiarch if the same package, > but compiled for a different architecture, would be installed. > > Next, you would create some program to manage those symlinks. If you > prefer to run firefox in 32bit mode by default, you could say > "update-multiarch --config firefox i386", and it would move symlinks > around so that /usr/bin/firefox, and all files from that package with > it, refer to the i386 version of firefox rather than the amd64 version, > or the ia64 one, or what have you. Note that this would require some packages to use the arch specific binaries. E.g. mkinitramfs or debian-installer need the right arch for their binaries. With the arch/bin dirs being optional those packages then have to support both ways. Another complication. With only one arch per binary only the Depends/Build-Depends have to be arch specific and not the scripts itself. > I mentioned the alternatives system because it already exists and it > does something similar to what I'm proposing; not because I'm proposing > you use exactly that to fix these issues. > > The whole point really is "why not use symlinks?" and "We've already > fixed a similar problem with symlinks", not "use the alternatives > system". The alternatives system is the exact and perfect solution to this problem and is already existing and working. Not using it just means you are duplicating its functionality. The only difference is that packages use alternatives manualy while you want dpkg to automagicaly add alternatives. The problem lies in this magic instead of the handfull of packages that would even need 32/64 bit implementing it themself. The only currently known case where users might want 32bit and 64bit of the same binary are browsers. And even for that there is no good reason why just 32bit isn't enough. 64bit is just wanted for the slight speed increase. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Thu, May 18, 2006 at 04:52:58PM +0200, Goswin von Brederlow wrote: > Wouter Verhelst <[EMAIL PROTECTED]> writes: > > > On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote: > >> Wouter Verhelst <[EMAIL PROTECTED]> writes: > >> > Have you considered employing the alternatives system (or something > >> > similar)? What I'm suggesting is that you'd basically get a /bin64 and a > >> > /bin32, where binaries install themselves in /bin by default but divert > >> > to the /binXX when both versions are installed, and use symlinks in an > >> > update-alternatives way to select the default. > >> > >> Each package that deems it neccessary can choose to do so. > > > > That's not what I meant, really. > > > >> I imagine the count to be near 0. Certainly nothing dpkg should handle > >> automagicaly for all debs. > > > > Why not? > > Extra complexity with extra risk of breaking for no practical gain. That could technically be said about all of multiarch... > Also don't forget that you can have more than 2 archs but dpkg can't > have more than 2 diversions. Err, okay. I guess I shouldn't have mentioned "alternatives", because that clearly confused you. What I meant to say is that you could have dpkg set up things so that if multiarch is in effect, files would be installed in /multiarch/i386/bin rather than in /bin (or some such), and that symlinks would be made to /bin so that the entire process would be transparent to a package. Alternatively, you could also set it up so that files would be installed in /bin by default, but then moved to /multiarch if the same package, but compiled for a different architecture, would be installed. Next, you would create some program to manage those symlinks. If you prefer to run firefox in 32bit mode by default, you could say "update-multiarch --config firefox i386", and it would move symlinks around so that /usr/bin/firefox, and all files from that package with it, refer to the i386 version of firefox rather than the amd64 version, or the ia64 one, or what have you. I mentioned the alternatives system because it already exists and it does something similar to what I'm proposing; not because I'm proposing you use exactly that to fix these issues. The whole point really is "why not use symlinks?" and "We've already fixed a similar problem with symlinks", not "use the alternatives system". -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote: >> Wouter Verhelst <[EMAIL PROTECTED]> writes: >> > Have you considered employing the alternatives system (or something >> > similar)? What I'm suggesting is that you'd basically get a /bin64 and a >> > /bin32, where binaries install themselves in /bin by default but divert >> > to the /binXX when both versions are installed, and use symlinks in an >> > update-alternatives way to select the default. >> >> Each package that deems it neccessary can choose to do so. > > That's not what I meant, really. > >> I imagine the count to be near 0. Certainly nothing dpkg should handle >> automagicaly for all debs. > > Why not? Extra complexity with extra risk of breaking for no practical gain. Also don't forget that you can have more than 2 archs but dpkg can't have more than 2 diversions. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Thu, May 18, 2006 at 03:23:44AM +0200, Goswin von Brederlow wrote: > But there will be times where the actual source version of debs for > each arch differs. Actualy at every upgarde that happens between arch1 > getting unpacked and arch2 getting unpacked as well. Dpkg just has to > handle it in some sane way. dpkg could just unconfigure (or even remove) all other arches before upgrading arch1, and allow configuring a new arch only if the version number (except for the binNMU component) is identical to the alread-configured arch. 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 status update
On Wed, May 17, 2006 at 10:08:38PM +0200, Goswin von Brederlow wrote: > Wouter Verhelst <[EMAIL PROTECTED]> writes: > > Have you considered employing the alternatives system (or something > > similar)? What I'm suggesting is that you'd basically get a /bin64 and a > > /bin32, where binaries install themselves in /bin by default but divert > > to the /binXX when both versions are installed, and use symlinks in an > > update-alternatives way to select the default. > > Each package that deems it neccessary can choose to do so. That's not what I meant, really. > I imagine the count to be near 0. Certainly nothing dpkg should handle > automagicaly for all debs. Why not? -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
#include * Goswin von Brederlow [Tue, May 16 2006, 11:55:18PM]: > What do you mean with invasive? Multiarch is designed to be > implemented without disrupting the existing archive or mono-arch > systems at any time. Each package can get converted to multiarch by > itself and once a substantial number of packages have done so a > multiarch dpkg/apt/aptitude can be used. And that is why I question it. Do we need that? You demonstrated that it is quite easy to setup the depencency chain for a package... but why should we care about change the whole distribution for the sake of few 3rd party packages if we have sufficient workarounds? > But cooking the packages is not 100% successfull and involves a lot of > diversions and alternatives. Every include file gets diverted, every > binary in a library gets an alternative. All cooked packages depend on > their uncooked other architecture version for pre/postinst/rm scripts, > forcing both arch to be installed even if only the cooked one is > needed. I don't see a bad problem with that, sounds like an acceptable compromise. > And still some things won't work without the multiarch dirs being used > by any software using dlopen and similar. That includes X locales, > gtk-pixmap, pango to start with. Such things are not okay but there could be few workarounds as well. > It works for a stable release but for unstable the constant stream of > changes needed in the cooking script would be very disruptive for > users. Only if you port the whole distribution. If you port few dozens of library packages, maintaining them should be feasible. > It also is disruptive to building packages. Build-Depends will only > work for the native arch and not for the cooked packages and > building for the cooked arch will give precooked Depends (I do cook > shlibs files) so they are invalid for uploads. This problem is only implied by "porting the whole arch and using everything like a native package". Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Darren Salt <[EMAIL PROTECTED]> writes: > I demand that Gabor Gombas may or may not have written... > > [snip] >> How do you want to handle one-arch-only binNMUs? binNMUs change >> changelog.Debian.gz, so >> - you can't upgrade just the architecture that was binNMUed without >> changelog.Debian.gz becoming invalid for the other arches > [snip] > > I think that this'll just have to be accepted - ignore the binNMU versioning > when comparing versions for co-installation, but take the docs from the > highest-numbered binNMU. > > I don't know how a binNMU for one architecture followed by a binNMU for > another is handled, but it seems reasonable to me that the newer one will > have to include the changelog from the older one and, therefore, must have a > higher version number. Otherwise, which binNMU changelog entry you get is a > matter of chance, and entries may even be lost in later uploads. Not to mention that binNMU for only one arch will be fixing a build screwup like a broken gcc version on that arch causing faulty binaries. And binNMUs for multiple/all archs will be to help transitions in their depends along. In both cases no change has been made to the source and the reason for the binNMU is quite irelevant to most users. But there will be times where the actual source version of debs for each arch differs. Actualy at every upgarde that happens between arch1 getting unpacked and arch2 getting unpacked as well. Dpkg just has to handle it in some sane way. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Ron Johnson <[EMAIL PROTECTED]> writes:
> On Wed, 2006-05-17 at 10:34 +0200, Goswin von Brederlow wrote:
>> Ron Johnson <[EMAIL PROTECTED]> writes:
>>
>> > On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote:
>> >> "Olaf van der Spek" <[EMAIL PROTECTED]> writes:
>> >>
>> >> > On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> >> >> Bill Allombert <[EMAIL PROTECTED]> writes:
>> >> >>
>> >> >> > On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote:
> [snip]
>> >>
>> >> We have thought hard about this over the last 2 years and nobody has
>> >> come up with a non disruptive way
>> >
>> > Is "non-disruptive" that vital? What about "minimally disruptive",
>> > or "a little disruptive"?
>> >
>> > As a user, I'd put up with some one-time disruption if that means
>> > that I could have 64-bit coolness (after all, I'm a home user) while
>> > keeping 32-bit goodness like OOo2 & w32codecs.
>>
>> But why would you want to put up with it at all? Do you realy need
>> both a 32bit OOo and a 64bit OOo? Or both 64bit and 32bit video
>> players? Isn't one of the two enough?
>
> No.
>
> $JOE_USER will, ISTM, only need to (want to)run a few 32-bit apps
> on his otherwise 64-bit system.
>
> OOo2 (until it becomes 64-bit clean)
> w32codecs (and thus every app that depends on it)
> Wine
> other OSS apps that aren't 64-bit clean
> binary apps:
> Adobe Acrobat Reader
> Macromedia Flash player
> Crossover Office
> Sun Java ?
>
> And this implies apps like Firefox, since many of these apps have
> plugins for FF & Mozilla, and the libraries they depend on. (Yes,
> closed source is impure, blah, blah, worship RMS, but the sad fact
> is that they are *useful*.)
>
>> By only alowing one arch per binary we have a totaly non disruptive
>> way of implementing multiarch that is fully upwards and downwards
>> compatible with etch (and only needs a ld.so.conf entry in
>> sarge). Allowing multiple archs for one binary just solves a problem
>> that we don't have and adds a ton of complexity not to mention changes
>> to packages. We are talking 100 vs. 16000.
>
> It looks like we agree on this. The scope should be narrow and
> "downhill", i.e., ia32 apps on x86_64, PPC32 apps on PPC64, SPARC32
> on SPARC64 systems. No uphill, and no complications like all the
> different MIPS permutations running together.
No. Only on ia64 and amd64 do you want to default to 64bit. Ia64
because 32bit mode is emulated and amd64 because the ton of extra
regioster make it faster in general. All other archs suffer from the
extra memory and bandwith required for the larger pointer and are
considerably slower in 64bit mode.
But it doesn't realy matter what you call up or downhill. One arch
gets set as prefered or each one gets a pin and the best one available
wins unless overrules by the user.
> Am I arguing for bi-arch? If so, so be it. KISS.
You are arguing not to have the same binary for multiple architecture
installed but different binaries from different architectures. Bi-arch
or multiarch is just implementation detail for you. It is what most
sane people want.
> Still, in a universe as large as Debian, some group of users must
> have a reason to need to/want to be able to install side-by-side
> architectures of the same packages.
>
> However, there's no need to make this totally transparent.
>
> People who want to run 32-bit apps in a 64-bit world would have
> to EXPLICITLY run a script that changes that process' personality
> (using linux32) and then runs /usr/bin/${SOMEAPP}_32.
Nah, linux32 just changes the output of uname. Nearly everything has
no need to query that information and you just start it. Alternatives
are much simpler and more transparent for the user.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
I demand that Gabor Gombas may or may not have written... [snip] > How do you want to handle one-arch-only binNMUs? binNMUs change > changelog.Debian.gz, so > - you can't upgrade just the architecture that was binNMUed without > changelog.Debian.gz becoming invalid for the other arches [snip] I think that this'll just have to be accepted - ignore the binNMU versioning when comparing versions for co-installation, but take the docs from the highest-numbered binNMU. I don't know how a binNMU for one architecture followed by a binNMU for another is handled, but it seems reasonable to me that the newer one will have to include the changelog from the older one and, therefore, must have a higher version number. Otherwise, which binNMU changelog entry you get is a matter of chance, and entries may even be lost in later uploads. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Output less CO2 => avoid boiling weather. TIME IS RUNNING OUT *FAST*. When you go out to buy, don't show your silver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Gabor Gombas <[EMAIL PROTECTED]> writes: > On Wed, May 17, 2006 at 12:14:24AM +0200, Goswin von Brederlow wrote: >> Multiarch (so far) does not allow the same path/file in 2 packages >> (with the exception of /usr/share/doc/ files) > > Hmm. How do you want to handle one-arch-only binNMUs? binNMUs change > changelog.Debian.gz, so > - you can't upgrade just the architecture that was binNMUed without > changelog.Debian.gz becoming invalid for the other arches > - there will be no new version for the other arches so you can't just > wait till the versions are in sync > > Gabor Afaik nothing in the package may depend on the existance of /usr/share/doc so it doesn't realy matter (to the package) what happens there. Handling the special overlap for changelog and readme files there can be implemented in several ways: 1) Don't care about it Just assume --force-overwrite for anything in /usr/share/doc. Whatever gets installed last sticks and removal of packages can lead to files getting removed and so on. A slightly better thing would be to always keep the highest version as that should include prior versions info as well. 2) Automaticaly divert This has the small problem of not workign with 3 or more archs since dpkg only handles one diversion. 3) Automaticaly append the arch tripplet to the files 4) Don't allow it Split those files off into architecture:all packages. For packages that have one anyway this is probably the sanest thing. But creating a package with just the changelog, copyright and readme is kind of insane. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Wed, May 17, 2006 at 12:01:08AM +0200, Goswin von Brederlow wrote: >> "Olaf van der Spek" <[EMAIL PROTECTED]> writes: >> > Why do you think there's no compatible solution? >> >> Because basicaly all sources assume binaries go to /bin. You >> want to break that. Also a lot of scripts expect binaries to be where >> they are and anything setting PATH too. > > Have you considered employing the alternatives system (or something > similar)? What I'm suggesting is that you'd basically get a /bin64 and a > /bin32, where binaries install themselves in /bin by default but divert > to the /binXX when both versions are installed, and use symlinks in an > update-alternatives way to select the default. Each package that deems it neccessary can choose to do so. I imagine the count to be near 0. Certainly nothing dpkg should handle automagicaly for all debs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Wed, 2006-05-17 at 10:34 +0200, Goswin von Brederlow wrote:
> Ron Johnson <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote:
> >> "Olaf van der Spek" <[EMAIL PROTECTED]> writes:
> >>
> >> > On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> >> >> Bill Allombert <[EMAIL PROTECTED]> writes:
> >> >>
> >> >> > On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote:
[snip]
> >>
> >> We have thought hard about this over the last 2 years and nobody has
> >> come up with a non disruptive way
> >
> > Is "non-disruptive" that vital? What about "minimally disruptive",
> > or "a little disruptive"?
> >
> > As a user, I'd put up with some one-time disruption if that means
> > that I could have 64-bit coolness (after all, I'm a home user) while
> > keeping 32-bit goodness like OOo2 & w32codecs.
>
> But why would you want to put up with it at all? Do you realy need
> both a 32bit OOo and a 64bit OOo? Or both 64bit and 32bit video
> players? Isn't one of the two enough?
No.
$JOE_USER will, ISTM, only need to (want to)run a few 32-bit apps
on his otherwise 64-bit system.
OOo2 (until it becomes 64-bit clean)
w32codecs (and thus every app that depends on it)
Wine
other OSS apps that aren't 64-bit clean
binary apps:
Adobe Acrobat Reader
Macromedia Flash player
Crossover Office
Sun Java ?
And this implies apps like Firefox, since many of these apps have
plugins for FF & Mozilla, and the libraries they depend on. (Yes,
closed source is impure, blah, blah, worship RMS, but the sad fact
is that they are *useful*.)
> By only alowing one arch per binary we have a totaly non disruptive
> way of implementing multiarch that is fully upwards and downwards
> compatible with etch (and only needs a ld.so.conf entry in
> sarge). Allowing multiple archs for one binary just solves a problem
> that we don't have and adds a ton of complexity not to mention changes
> to packages. We are talking 100 vs. 16000.
It looks like we agree on this. The scope should be narrow and
"downhill", i.e., ia32 apps on x86_64, PPC32 apps on PPC64, SPARC32
on SPARC64 systems. No uphill, and no complications like all the
different MIPS permutations running together.
Am I arguing for bi-arch? If so, so be it. KISS.
Still, in a universe as large as Debian, some group of users must
have a reason to need to/want to be able to install side-by-side
architectures of the same packages.
However, there's no need to make this totally transparent.
People who want to run 32-bit apps in a 64-bit world would have
to EXPLICITLY run a script that changes that process' personality
(using linux32) and then runs /usr/bin/${SOMEAPP}_32.
--
-
Ron Johnson, Jr.
Jefferson, LA USA
The enemy thinks and plans and strategizes, too.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Wed, May 17, 2006 at 12:14:24AM +0200, Goswin von Brederlow wrote: > Wait a second. How do you create the dir when the file already exists? There was quite some talk on linux-kernel about 'every-file-is-a-directory' approaches when Reiserfs 4 was released. Some said they'd like to see this feature in other file systems if only someone got the nerve to design & implement the needed VFS extensions. > Say I have /usr/bin/firefox/i486 and /usr/bin/firefox/x86_64. Which > one should be the default? Where/how do I set the default? This is just theory, but if you implement the 'every-file-is-a-directory' concept with extended attributes then - /usr/bin/firefox is just a stub file containing a magic cookie - the per-architecture binaries are stored as EAs - there can be a 'default' EA pointing to the default architecture, so you can set the default separately for every binary - a binfmt_misc helper should be created that intercepts the magic cookie in the stub file and loads the binary from the appropriate EA This way running /usr/bin/firefox gives you the defalt arch, and /usr/bin/firefox/$ARCH (or /usr/bin/[EMAIL PROTECTED] or whatever syntax you define for accessing the EAs) gives you the binary for the specific arch. > I never use flash so I want the x86_64 default. But userB always uses > flash and wants i486. How do you set that up per user? This problem already exists with alternatives regardless of multiarch. The sysadmin sets up JDK-1.5 as default using the alternatives system but userB always uses JDK-1.4. How do you set that up per user? alias firefox=/usr/bin/firefox/i486 works just fine for userB. > Multiarch (so far) does not allow the same path/file in 2 packages > (with the exception of /usr/share/doc/ files) Hmm. How do you want to handle one-arch-only binNMUs? binNMUs change changelog.Debian.gz, so - you can't upgrade just the architecture that was binNMUed without changelog.Debian.gz becoming invalid for the other arches - there will be no new version for the other arches so you can't just wait till the versions are in sync 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 status update
On Tue, May 16, 2006 at 06:02:58PM +0200, Romain Beauxis wrote: > Few things that I see: > -- FUSE goes throught userland <-> kernel <-> Userland so it: > ** May be an overhead for all /usr/bin calls. Sure. Every feature has a price. In reality I expect the dentry cache and the page cache takes care about the heavily used binaries. In any case it will be still faster than NFS and people do use NFS for mounting /usr. > ** May be a potential security leak, like using LD_PRELOAD for a given user > and use a custom fuse library for this user, with *any* /usr/bin filesystem > you like Only if you allow normal users over-mounting /usr/bin. I was only talking about a system-wide mount. > -- FUSE module is not loaded by default, and some server maintainer would > like > te reFUSE using it... :-) mount --bind /usr/lib/$DEFAULT_ARCH/bin /usr/bin and you are done. The FUSE solution is only needed if you want dynamic per-binary architecture selection. > -- Furthermore, what to do during bootstrap of the root file system? Because > this should also be needed for /bin, so again overhead, security and loading > at en early stage is not a solution for me... mount --bind /bin-$DEFAULT_ARCH /bin during boot. Or simply state that /bin and /sbin are not multiarched. 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 status update
On Wed, May 17, 2006 at 12:01:08AM +0200, Goswin von Brederlow wrote: > "Olaf van der Spek" <[EMAIL PROTECTED]> writes: > > Why do you think there's no compatible solution? > > Because basicaly all sources assume binaries go to /bin. You > want to break that. Also a lot of scripts expect binaries to be where > they are and anything setting PATH too. Have you considered employing the alternatives system (or something similar)? What I'm suggesting is that you'd basically get a /bin64 and a /bin32, where binaries install themselves in /bin by default but divert to the /binXX when both versions are installed, and use symlinks in an update-alternatives way to select the default. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Ron Johnson <[EMAIL PROTECTED]> writes: > On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote: >> "Olaf van der Spek" <[EMAIL PROTECTED]> writes: >> >> > On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >> >> Bill Allombert <[EMAIL PROTECTED]> writes: >> >> >> >> > On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote: >> >> >> I so far haven't seen any compelling arguments for multiarchifying the >> >> >> whole archive including all of */bin. >> >> > >> >> > Personnally I would favor a new files hierachy that allow every >> >> > arch-dependend files to be co-installable. Even if we are not able to >> >> > take full advantage of it at once, it seems saner and more >> >> > forward-looking >> >> > than only allowing libraries to be co-installable. This might also make >> >> > easier to have this new scheme adopted by other OS. >> >> > >> >> > Cheers, >> >> >> >> But would make it totaly incompatible with existing systems. >> > >> > Why do you think there's no compatible solution? >> >> Because basicaly all sources assume binaries go to /bin. You >> want to break that. Also a lot of scripts expect binaries to be where >> they are and anything setting PATH too. >> >> We have thought hard about this over the last 2 years and nobody has >> come up with a non disruptive way > > Is "non-disruptive" that vital? What about "minimally disruptive", > or "a little disruptive"? > > As a user, I'd put up with some one-time disruption if that means > that I could have 64-bit coolness (after all, I'm a home user) while > keeping 32-bit goodness like OOo2 & w32codecs. But why would you want to put up with it at all? Do you realy need both a 32bit OOo and a 64bit OOo? Or both 64bit and 32bit video players? Isn't one of the two enough? By only alowing one arch per binary we have a totaly non disruptive way of implementing multiarch that is fully upwards and downwards compatible with etch (and only needs a ld.so.conf entry in sarge). Allowing multiple archs for one binary just solves a problem that we don't have and adds a ton of complexity not to mention changes to packages. We are talking 100 vs. 16000. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote: > "Olaf van der Spek" <[EMAIL PROTECTED]> writes: > > > On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > >> Bill Allombert <[EMAIL PROTECTED]> writes: > >> > >> > On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote: > >> >> I so far haven't seen any compelling arguments for multiarchifying the > >> >> whole archive including all of */bin. > >> > > >> > Personnally I would favor a new files hierachy that allow every > >> > arch-dependend files to be co-installable. Even if we are not able to > >> > take full advantage of it at once, it seems saner and more > >> > forward-looking > >> > than only allowing libraries to be co-installable. This might also make > >> > easier to have this new scheme adopted by other OS. > >> > > >> > Cheers, > >> > >> But would make it totaly incompatible with existing systems. > > > > Why do you think there's no compatible solution? > > Because basicaly all sources assume binaries go to /bin. You > want to break that. Also a lot of scripts expect binaries to be where > they are and anything setting PATH too. > > We have thought hard about this over the last 2 years and nobody has > come up with a non disruptive way Is "non-disruptive" that vital? What about "minimally disruptive", or "a little disruptive"? As a user, I'd put up with some one-time disruption if that means that I could have 64-bit coolness (after all, I'm a home user) while keeping 32-bit goodness like OOo2 & w32codecs. > to change binary location that is > both upwards and downwards compatible. That certainly isn't a proof > but untill someone comes up with a solution I will keep asuming there > is none. -- - Ron Johnson, Jr. Jefferson, LA USA "Politics is not the art of the possible. It consists in choosing between the disastrous and the unpalatable." John Kenneth Galbraith -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
> > But say you have the old i486 ls installed in /bin/ls and now you > install the new amd64 ls in /bin/ls/x86_64. > > Wait a second. How do you create the dir when the file already exists? > dpkg has to specialy handle this case for every package. > That's probably a bit of a problem. But that doesn't detract from the usefulness of being able to have multiple binaries with the same path IMO. > >> Also what architecture should be called on x86_64 if both are there? > >> i486 or amd64? Should that be configurable? > >> > > > > What do you mean here ? > > Say I have /usr/bin/firefox/i486 and /usr/bin/firefox/x86_64. Which > one should be the default? Where/how do I set the default? > The default would then be x86_64. I don't remember if AIX had a per process setting to change this. > I never use flash so I want the x86_64 default. But userB always uses > flash and wants i486. How do you set that up per user? > You could use something like prctl for this. Note that current multiarch doesn't solve this problem either. > > But /bin/sh then is a directory containing i486 and x86_64. Or just > one of them. Or cotaining mips, mipsn32, mips64, mipsel, mipsn32el, > mips64el, mips-abi32, mips-abi64, mips-abi32el, mips-abi64el. > So ? There is no difference between executing /bin/sh directly and having it done as an interpreter for a script. L & L p2. -- goa is a state of mind signature.asc Description: Digital signature
Re: multiarch status update
Peter 'p2' De Schrijver <[EMAIL PROTECTED]> writes: >> Lets say we do add special dirs for binaries and let dpkg manage >> them. How would that work with old and new debs mixed together? Should >> dpkg move all binaries into subdirs on upgrade once? Should it move >> binaries into subdirs when a second arch gets installed? >> > > It is possible to have both 'normal' and 'directory' binaries at the > same time. At least AIX managed to do that, although I don't exactly > know how it did that. So this problem is probably non existant. But say you have the old i486 ls installed in /bin/ls and now you install the new amd64 ls in /bin/ls/x86_64. Wait a second. How do you create the dir when the file already exists? dpkg has to specialy handle this case for every package. >> Also what architecture should be called on x86_64 if both are there? >> i486 or amd64? Should that be configurable? >> > > What do you mean here ? Say I have /usr/bin/firefox/i486 and /usr/bin/firefox/x86_64. Which one should be the default? Where/how do I set the default? I never use flash so I want the x86_64 default. But userB always uses flash and wants i486. How do you set that up per user? >> I imagine that would need kernel support to work for "#!/bin/sh" and >> the like which again raises the question of compatibility. >> >> > > No. #!/bin/sh would just execute /bin/sh as usual. But /bin/sh then is a directory containing i486 and x86_64. Or just one of them. Or cotaining mips, mipsn32, mips64, mipsel, mipsn32el, mips64el, mips-abi32, mips-abi64, mips-abi32el, mips-abi64el. >> Weigh the gain against the work and hopefully you will see that the >> cost outweigh the gain by a lot. If you want to share a filesystem to >> i486 and amd64 systems I guess you could use a unionfs for amd64 that >> has i486 as base and then just adds the 64bit stuff. Thats probably >> far simpler and better than adding the complexity to dpkg. >> > > Well no. Because there is far more use then i486 and amd64. I don't > think dpkg needs extra changes beyond being able to install packages for > another architecture and doing the dependencies per architecture (which > all is necessary for multiarch anyway). Multiarch (so far) does not allow the same path/file in 2 packages (with the exception of /usr/share/doc/ files) and all library packages have to move files so they are disjunct. You want more it seems. > L & L > > p2. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Eduard Bloch <[EMAIL PROTECTED]> writes: > #include > * Matt Taggart and others [Wed, May 10 2006, 02:00:47AM]: > >> http://wiki.debian.org/multiarch > > Looking at all that I have a simple question: do we need a such kind of > invasive multiarch integration. There only things I have to use which > are not available for native amd64. For this things, we could create > "installer" packages which integrate that software and cook the whole > dependency chain from i386 Debian packages, by relocating the files and > editing the package attributes. This workaround can be created (or is > already created) full painless than introducing a whole multiarch > system. I agree with people argumenting that sometimes using i386 > versions does mean real speedup but I don't believe that this does > count. > > Eduard. What do you mean with invasive? Multiarch is designed to be implemented without disrupting the existing archive or mono-arch systems at any time. Each package can get converted to multiarch by itself and once a substantial number of packages have done so a multiarch dpkg/apt/aptitude can be used. There is some disruption to package sources but a lot of that is enforcing policy compliance, e.g. split binaries and conffiles out of library packages. I've written cross-archive (in the multiarch repository on alioth) to cook amd64 files to be coinstallable with i386 and am using that on a number of cluster system at work for a biarch 32/64 environment. Its predecessor (amd64-archive) is still in use by many people for OOo on amd64. But cooking the packages is not 100% successfull and involves a lot of diversions and alternatives. Every include file gets diverted, every binary in a library gets an alternative. All cooked packages depend on their uncooked other architecture version for pre/postinst/rm scripts, forcing both arch to be installed even if only the cooked one is needed. And still some things won't work without the multiarch dirs being used by any software using dlopen and similar. That includes X locales, gtk-pixmap, pango to start with. It also means the cooking has to patch maintainer scripts on the fly making it fragile with regard to changes in the debs it cooks. It works for a stable release but for unstable the constant stream of changes needed in the cooking script would be very disruptive for users. It also is disruptive to building packages. Build-Depends will only work for the native arch and not for the cooked packages and building for the cooked arch will give precooked Depends (I do cook shlibs files) so they are invalid for uploads. The one big reason for multiarch over biarch (manual or cooked) always has been to preserve Build-Depends and Depends lines in nearly all cases. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Olaf van der Spek" <[EMAIL PROTECTED]> writes: > On 5/15/06, Pierre Habouzit <[EMAIL PROTECTED]> wrote: >> Le Dim 14 Mai 2006 21:11, Olaf van der Spek a écrit : >> > > - Why would you want to have both types installed simultaneously >> > > anyway? >> > > >> > > For libraries the answer is simple, but multiarch applications >> > > simply don't seem useful to me. The solution would be to either >> > > forbid having >> > >> > Consider for example 32-bit and 64-bit Firefox with some extensions >> > only available for 32-bit and others only for 64-bit. >> >> this is a dream. This also need that the application is able to deal >> with the fact that it has configuration for the 32 and 64 bits version >> coexisting cleanly. > > True. Did I say that it would be trivial? > Or even a short-term solution? Algorithmicaly it is trivial: /etc/firefox/plugins.x86_64-linux-gnu /etc/firefox/plugins.i486-linux-gnu or /etc/x86_64-linux-gnu/firefox/... >> given the crap that is firefox configuration, you won't be able to have >> different lists of plugins for the 32 and 64 bits versions at the same >> time. > > Firefox was just an example. But a good one. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Olaf van der Spek" <[EMAIL PROTECTED]> writes: > On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >> Bill Allombert <[EMAIL PROTECTED]> writes: >> >> > On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote: >> >> I so far haven't seen any compelling arguments for multiarchifying the >> >> whole archive including all of */bin. >> > >> > Personnally I would favor a new files hierachy that allow every >> > arch-dependend files to be co-installable. Even if we are not able to >> > take full advantage of it at once, it seems saner and more forward-looking >> > than only allowing libraries to be co-installable. This might also make >> > easier to have this new scheme adopted by other OS. >> > >> > Cheers, >> >> But would make it totaly incompatible with existing systems. > > Why do you think there's no compatible solution? Because basicaly all sources assume binaries go to /bin. You want to break that. Also a lot of scripts expect binaries to be where they are and anything setting PATH too. We have thought hard about this over the last 2 years and nobody has come up with a non disruptive way to change binary location that is both upwards and downwards compatible. That certainly isn't a proof but untill someone comes up with a solution I will keep asuming there is none. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Tollef Fog Heen <[EMAIL PROTECTED]> writes: > Pierre Habouzit wrote: > >> honnestly, please find *ONE* application where alternatives can't >> solve your problem, and where upstream design would still allow to >> have both instances installed. I've though hard enough, and I've >> found none. > > You might want to have, say, multiple installations of apache (because > the 32 bit version uses PHP and you use a proprietary PHP plugin), > while you want to serve DVD images with your 64 bit apache (since > apache 2.2 isn't in unstable yet and so you need a 64 bit apache to > handle > 2GB files on 32 bit platforms). > > Your point still holds though, applications where coinstallation is > needed are rare and in those cases applications can either implement a > solution themselves or tell the user to use /usr/local or ~. > > - tfheen But those apaches have to run on different ports or they should switch over seemlessly whenever the php plugin is used. So this needs a certain amount of package adoption already. Lets just add the alternatives there too. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Scripsit "Olaf van der Spek" <[EMAIL PROTECTED]> > On 5/16/06, Dagfinn Ilmari Mannsåker <[EMAIL PROTECTED]> wrote: >> Here's an idea: store the configuration meta data in the file itself, >> say, in the first line, following a comment starting with an exclamation >> mark. > This would kill MD5 checksums of changed files... No it wouldn't. The metadata that says which version of Python the program is written in is put there by the Debian maintainer and stays content. The metadata the says which binary on the system implements that version of Python is represented by links in the file system. What do you think the problem is? -- Henning Makholm "Also, the letters are printed. That makes the task of identifying the handwriting much more difficult." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
> > I don't think so. I see at least a few possible uses for this : > > > > 1) have a shared filesystem between machines of multiple architectures > > 2) test your programs on architectures you don't have by using qemu > > It might have its use there but it can't be simply done. The files > from two packages must be disjunct. That was my point. Moving binaries > into subdirs and calling them by their arch (e.g. /bin/ls/i486) would > solve that. But something has to do this change. Either the packaging > itself or dpkg when unpacking the deb. Both would mean a major change > in what we (and everybody else) currently have. > That could just be part of the package. Ie. unpacking the files automatically puts them at the right place. > Lets say we do add special dirs for binaries and let dpkg manage > them. How would that work with old and new debs mixed together? Should > dpkg move all binaries into subdirs on upgrade once? Should it move > binaries into subdirs when a second arch gets installed? > It is possible to have both 'normal' and 'directory' binaries at the same time. At least AIX managed to do that, although I don't exactly know how it did that. So this problem is probably non existant. > Also what architecture should be called on x86_64 if both are there? > i486 or amd64? Should that be configurable? > What do you mean here ? > I imagine that would need kernel support to work for "#!/bin/sh" and > the like which again raises the question of compatibility. > > No. #!/bin/sh would just execute /bin/sh as usual. > Weigh the gain against the work and hopefully you will see that the > cost outweigh the gain by a lot. If you want to share a filesystem to > i486 and amd64 systems I guess you could use a unionfs for amd64 that > has i486 as base and then just adds the 64bit stuff. Thats probably > far simpler and better than adding the complexity to dpkg. > Well no. Because there is far more use then i486 and amd64. I don't think dpkg needs extra changes beyond being able to install packages for another architecture and doing the dependencies per architecture (which all is necessary for multiarch anyway). L & L p2. -- goa is a state of mind signature.asc Description: Digital signature
Re: multiarch status update
Peter 'p2' De Schrijver <[EMAIL PROTECTED]> writes: >> > Being able to install multiple versions is some use to multiarch, but >> > could also be used for other things, such if two packages provide the >> > same binary (git for example). >> > Or to install multiple 'version 'numbers' of the same package. >> >> The big problem then is when to install multiple versions of a binary? >> How should the depends decide when that is needed or wanted and when >> not? Esspecialy when different versions are available per >> architecture. >> > > One way of doing this would be to make a binary a special directory > which contains the actual binary files for the architectures the > binaries exist. AIX 1.x did this and allowed transparent execution of > binaries in a heterogenous cluster. So if you would start a binary on > IA32 AIX machine which only existed in a mainframe AIX version, the > system would automatically start the binary on one of the mainframe AIX > nodes in the cluster. If an IA32 AIX binary was available, it would > locally start this binary. The 'binary directory' had the name, the > binary would normally have. The actual binary files get the architecture > name they implement as the filename. Eg: there would be an /bin/ls > directory containing 2 files : i386, ibm370. > >> How would programs or user specifiy what binary to call? How would > > You could explicitly start /bin/ls/i386 I think (which would fail if > you did it on the wrong machine). > >> users even know which binary is which if they have the same name and >> both packages are installed on the system? Just imagine the confusion >> of a user installing foo (which provides the same binary "foo" as bar) >> and calling foo gives him bars "foo". >> >> That is totaly out of the question. Packages that provide the same (by >> name) binary (or even just file) MUST conflict. period. >> > > I don't think so. I see at least a few possible uses for this : > > 1) have a shared filesystem between machines of multiple architectures > 2) test your programs on architectures you don't have by using qemu It might have its use there but it can't be simply done. The files from two packages must be disjunct. That was my point. Moving binaries into subdirs and calling them by their arch (e.g. /bin/ls/i486) would solve that. But something has to do this change. Either the packaging itself or dpkg when unpacking the deb. Both would mean a major change in what we (and everybody else) currently have. Lets say we do add special dirs for binaries and let dpkg manage them. How would that work with old and new debs mixed together? Should dpkg move all binaries into subdirs on upgrade once? Should it move binaries into subdirs when a second arch gets installed? Also what architecture should be called on x86_64 if both are there? i486 or amd64? Should that be configurable? I imagine that would need kernel support to work for "#!/bin/sh" and the like which again raises the question of compatibility. Weigh the gain against the work and hopefully you will see that the cost outweigh the gain by a lot. If you want to share a filesystem to i486 and amd64 systems I guess you could use a unionfs for amd64 that has i486 as base and then just adds the 64bit stuff. Thats probably far simpler and better than adding the complexity to dpkg. > L & L > > p2. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Tuesday 16 May 2006 17:53, Gabor Gombas wrote: > However, you can take this idea further: provided you have multiarched > binaries, you could create a small file system using FUSE that generates > such a wrapper on-the-fly based on the requested file name, and you > could mount this file system as /usr/bin. Voila. Hum, mounting FUSE file system at /usr/bin seems a bit weak to me. I love using FUSE as an additional file system, but using it as a core file system seems a bit exagerated for me. Few things that I see: -- FUSE goes throught userland <-> kernel <-> Userland so it: ** May be an overhead for all /usr/bin calls. ** May be a potential security leak, like using LD_PRELOAD for a given user and use a custom fuse library for this user, with *any* /usr/bin filesystem you like -- FUSE module is not loaded by default, and some server maintainer would like te reFUSE using it... :-) -- Furthermore, what to do during bootstrap of the root file system? Because this should also be needed for /bin, so again overhead, security and loading at en early stage is not a solution for me... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote: > That's great. Could you tell me how to use those so that script A uses > python 2.3 and script B uses python 2.4 without modifying the scripts? That's trivial. Create a wrapper that somehow decides which python version to run and launches the application using the right interpreter. Install the wrapper as /usr/bin/python instead of the current symlink and you're done. No kernel support, no dpkg support, no apt support is needed. However, you can take this idea further: provided you have multiarched binaries, you could create a small file system using FUSE that generates such a wrapper on-the-fly based on the requested file name, and you could mount this file system as /usr/bin. Voila. The _real_ difficulties for supporting multiarched binaries are: - Transitioning every single binary from /usr/bin to /usr/lib/$ARCH/bin. Looking at the current /usr/X11R6 transition this is less than trivial. There may be tricks like moving the old /usr/bin to /usr/lib/fallback_arch/bin before mounting the "wrapper" filesystem over /usr/bin, and redirect every writes to /usr/bin to /usr/lib/fallback_arch/bin; that may fool dpkg enough so package management continues to work during the transition. - Decide which version/architecture to run if the user requests /usr/bin/blah. With the FUSE approach this can be made a per-user decision if someone dares to go through all the implications of a setuid program seeing a different /usr/bin/foo than a non-setuid program. 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 status update
> > The obvious problem here: The scheme is incompatible with non-multiarched > software. It would at least require a package manager which specialcases > /bin directory, a one-time conversion which moves the binaries, and > some trickery for alternatives. Plus some more things which don't come > to mind immediately, I guess. > Hmm. I somehow recall that you could also do normal binaries. At least I can't remember that I always made this sort of 'binaries'. I'm not sure how AIX distinguished between both types though. I guess the 'directory binaries' had some magic bit set. L & L p2. -- goa is a state of mind signature.asc Description: Digital signature
Re: multiarch status update
On 5/16/06, Tollef Fog Heen <[EMAIL PROTECTED]> wrote: Olaf van der Spek wrote: > That depends on the implementation but I don't think it's not solvable. There's a bunch of claims from people who have worked on multiarch-related problems for a few years. You seem to think those claims are bogus, so I suggest you write up a solution which does all Which claims are you referring too and where did I say those are bogus? you think it should do instead of waving your hands about and saying "I think this is solvable".
Re: multiarch status update
Pierre Habouzit wrote: honnestly, please find *ONE* application where alternatives can't solve your problem, and where upstream design would still allow to have both instances installed. I've though hard enough, and I've found none. You might want to have, say, multiple installations of apache (because the 32 bit version uses PHP and you use a proprietary PHP plugin), while you want to serve DVD images with your 64 bit apache (since apache 2.2 isn't in unstable yet and so you need a 64 bit apache to handle > 2GB files on 32 bit platforms). Your point still holds though, applications where coinstallation is needed are rare and in those cases applications can either implement a solution themselves or tell the user to use /usr/local or ~. - tfheen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Olaf van der Spek wrote: That depends on the implementation but I don't think it's not solvable. There's a bunch of claims from people who have worked on multiarch-related problems for a few years. You seem to think those claims are bogus, so I suggest you write up a solution which does all you think it should do instead of waving your hands about and saying "I think this is solvable". - tfheen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/16/06, Dagfinn Ilmari Mannsåker <[EMAIL PROTECTED]> wrote: "Olaf van der Spek" <[EMAIL PROTECTED]> writes: > On 5/16/06, Dagfinn Ilmari Mannsåker <[EMAIL PROTECTED]> wrote: >> > I don't care about the implementation details, but if it requires >> > kernel support, then yes. >> >> How should the kernel (or any other implementation) know which script >> requires which python version without the scripts declaring it? > > Via configuration / meta data, a bit like package dependencies work now. Here's an idea: store the configuration meta data in the file itself, say, in the first line, following a comment starting with an exclamation mark. On 5/14/06, Michal Čihař <[EMAIL PROTECTED]> wrote: This would kill MD5 checksums of changed files...
Re: multiarch status update
"Olaf van der Spek" <[EMAIL PROTECTED]> writes: > On 5/16/06, Dagfinn Ilmari Mannsåker <[EMAIL PROTECTED]> wrote: >> > I don't care about the implementation details, but if it requires >> > kernel support, then yes. >> >> How should the kernel (or any other implementation) know which script >> requires which python version without the scripts declaring it? > > Via configuration / meta data, a bit like package dependencies work now. Here's an idea: store the configuration meta data in the file itself, say, in the first line, following a comment starting with an exclamation mark. -- ilmari "A disappointingly low fraction of the human race is, at any given time, on fire." - Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/16/06, Dagfinn Ilmari Mannsåker <[EMAIL PROTECTED]> wrote: > I don't care about the implementation details, but if it requires > kernel support, then yes. How should the kernel (or any other implementation) know which script requires which python version without the scripts declaring it? Via configuration / meta data, a bit like package dependencies work now.
Re: multiarch status update
"Olaf van der Spek" <[EMAIL PROTECTED]> writes: > On 5/16/06, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: >> On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote: >> >> See the system calls link(2) and symlink(2). The (Essential) coreutils >> >> package provides a userspace binary /bin/ln which makes these calls >> >> available to shell scripts. >> > That's great. Could you tell me how to use those so that script A uses >> > python 2.3 and script B uses python 2.4 without modifying the scripts? >> >> Are you seriously proposing adding runtime python version selection to the >> kernel? > > I don't care about the implementation details, but if it requires > kernel support, then yes. How should the kernel (or any other implementation) know which script requires which python version without the scripts declaring it? -- ilmari "A disappointingly low fraction of the human race is, at any given time, on fire." - Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/16/06, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote: >> See the system calls link(2) and symlink(2). The (Essential) coreutils >> package provides a userspace binary /bin/ln which makes these calls >> available to shell scripts. > That's great. Could you tell me how to use those so that script A uses > python 2.3 and script B uses python 2.4 without modifying the scripts? Are you seriously proposing adding runtime python version selection to the kernel? I don't care about the implementation details, but if it requires kernel support, then yes.
Re: multiarch status update
On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote: >> See the system calls link(2) and symlink(2). The (Essential) coreutils >> package provides a userspace binary /bin/ln which makes these calls >> available to shell scripts. > That's great. Could you tell me how to use those so that script A uses > python 2.3 and script B uses python 2.4 without modifying the scripts? Are you seriously proposing adding runtime python version selection to the kernel? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/16/06, Henning Makholm <[EMAIL PROTECTED]> wrote: Scripsit "Olaf van der Spek" <[EMAIL PROTECTED]> > Not true. For example, the kernel could be changed to pick the right > Python binary if it sees #!/usr/bin/python. There is already a hook for doing that that in the kernel; no patching is required. See the system calls link(2) and symlink(2). The (Essential) coreutils package provides a userspace binary /bin/ln which makes these calls available to shell scripts. That's great. Could you tell me how to use those so that script A uses python 2.3 and script B uses python 2.4 without modifying the scripts?
Re: multiarch status update
Scripsit "Olaf van der Spek" <[EMAIL PROTECTED]> > Not true. For example, the kernel could be changed to pick the right > Python binary if it sees #!/usr/bin/python. There is already a hook for doing that that in the kernel; no patching is required. See the system calls link(2) and symlink(2). The (Essential) coreutils package provides a userspace binary /bin/ln which makes these calls available to shell scripts. -- Henning Makholm"Grisene fik gåsehud" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Peter 'p2' De Schrijver wrote: > > > Being able to install multiple versions is some use to multiarch, but > > > could also be used for other things, such if two packages provide the > > > same binary (git for example). > > > Or to install multiple 'version 'numbers' of the same package. > > > > The big problem then is when to install multiple versions of a binary? > > How should the depends decide when that is needed or wanted and when > > not? Esspecialy when different versions are available per > > architecture. > > > > One way of doing this would be to make a binary a special directory > which contains the actual binary files for the architectures the > binaries exist. AIX 1.x did this and allowed transparent execution of > binaries in a heterogenous cluster. So if you would start a binary on > IA32 AIX machine which only existed in a mainframe AIX version, the > system would automatically start the binary on one of the mainframe AIX > nodes in the cluster. If an IA32 AIX binary was available, it would > locally start this binary. The 'binary directory' had the name, the > binary would normally have. The actual binary files get the architecture > name they implement as the filename. Eg: there would be an /bin/ls > directory containing 2 files : i386, ibm370. > > > How would programs or user specifiy what binary to call? How would > > You could explicitly start /bin/ls/i386 I think (which would fail if > you did it on the wrong machine). The obvious problem here: The scheme is incompatible with non-multiarched software. It would at least require a package manager which specialcases /bin directory, a one-time conversion which moves the binaries, and some trickery for alternatives. Plus some more things which don't come to mind immediately, I guess. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
> > Being able to install multiple versions is some use to multiarch, but > > could also be used for other things, such if two packages provide the > > same binary (git for example). > > Or to install multiple 'version 'numbers' of the same package. > > The big problem then is when to install multiple versions of a binary? > How should the depends decide when that is needed or wanted and when > not? Esspecialy when different versions are available per > architecture. > One way of doing this would be to make a binary a special directory which contains the actual binary files for the architectures the binaries exist. AIX 1.x did this and allowed transparent execution of binaries in a heterogenous cluster. So if you would start a binary on IA32 AIX machine which only existed in a mainframe AIX version, the system would automatically start the binary on one of the mainframe AIX nodes in the cluster. If an IA32 AIX binary was available, it would locally start this binary. The 'binary directory' had the name, the binary would normally have. The actual binary files get the architecture name they implement as the filename. Eg: there would be an /bin/ls directory containing 2 files : i386, ibm370. > How would programs or user specifiy what binary to call? How would You could explicitly start /bin/ls/i386 I think (which would fail if you did it on the wrong machine). > users even know which binary is which if they have the same name and > both packages are installed on the system? Just imagine the confusion > of a user installing foo (which provides the same binary "foo" as bar) > and calling foo gives him bars "foo". > > That is totaly out of the question. Packages that provide the same (by > name) binary (or even just file) MUST conflict. period. > I don't think so. I see at least a few possible uses for this : 1) have a shared filesystem between machines of multiple architectures 2) test your programs on architectures you don't have by using qemu L & L p2. -- goa is a state of mind signature.asc Description: Digital signature
Re: multiarch status update
On 5/15/06, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > > Why would you see many binaries installed from the user point of > > view? with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] > > For example because one user would like to have the absolute latest > version of a certain package while other users are satisfied with the > version in stable or testing. > > Or because you've got scripts that depend on php4 while you've also > got scripts that depend on php5. > > Or because you'd like to compile a binary with libmysqlclient14-dev > and then compile a binary with libmysqlclient15-dev. yes, but for the cases you mention, there is real reasons to stick with one or the other *versions* of the software. Here we talk about the *same* version of the package, but with different archs. While it makes sense for libraries, because you may want the But the problems and solutions are partly overlapping. honnestly, please find *ONE* application where alternatives can't solve your problem, and where upstream design would still allow to have both My problem? I didn't have a problem that required multiples arches of one application to be installed.
Re: multiarch status update
Le Lun 15 Mai 2006 17:02, Olaf van der Spek a écrit : > On 5/15/06, Romain Beauxis <[EMAIL PROTECTED]> wrote: > > I have a multiarch on my amd64 system only because I want to use > > applications that I can't use or does not have the same > > functionalities with amd64 (mostly firefox, ooo and mplayer > > then...). > > But I'll be happy to have a full amd64 system if only they could > > provide the same with it. > > > > So, as for Pierre, a binary package per multiarch system seems > > obviously the solution, since a user needs only a given > > functionalities. > > > > Why would you see many binaries installed from the user point of > > view? with a subject of "unsubscribe". Trouble? Contact > > [EMAIL PROTECTED] > > For example because one user would like to have the absolute latest > version of a certain package while other users are satisfied with the > version in stable or testing. > > Or because you've got scripts that depend on php4 while you've also > got scripts that depend on php5. > > Or because you'd like to compile a binary with libmysqlclient14-dev > and then compile a binary with libmysqlclient15-dev. yes, but for the cases you mention, there is real reasons to stick with one or the other *versions* of the software. Here we talk about the *same* version of the package, but with different archs. While it makes sense for libraries, because you may want the $arch1 version of foo that needs libquux in $arch1 *and* bar in $arch2 that needs libquux also but for $arch2, you obviously need multiarch for libraries. but I just cannot find any compelling reason to have multiarch for binaries. Sometimes you want i386 browsers to make use of flash/java/... plugins, or you want amd64 ocaml so that string are not limited to a length a bit smaller than 16Mb, ... but I see no real case of applications that you need in both arches at the same time. And even if that was the case, I pretend that it is a case by case problem, and that it does not makes sense to force every single binary package to be multiarch-friendly. For libs that will already be hard enough. And for the few (and I still need a *good* example of such a software) that needs it, a configuration through alternatives seems to solve the problem, and that is a technology we already understand and work with every day. Another point is that for libraries, you need that or that version of the library, and the linker will always choose the adequate one. For a binary, if I want 'foo', I have to chose once for all (through $PATH) if I prefer 64bits over 32bits *OR* the reverse. Which makes no sense at all to me. Sometimes you prefer the 64 bits version, sometimes the other. alternatives are good at it. any other system seems broken to me. honnestly, please find *ONE* application where alternatives can't solve your problem, and where upstream design would still allow to have both instances installed. I've though hard enough, and I've found none. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpWPB1c8ZMMc.pgp Description: PGP signature
Re: multiarch status update
On 5/15/06, Romain Beauxis <[EMAIL PROTECTED]> wrote: Hi all! On Monday 15 May 2006 14:15, Olaf van der Spek wrote: > > this is a dream. This also need that the application is able to deal > > with the fact that it has configuration for the 32 and 64 bits version > > coexisting cleanly. > > True. Did I say that it would be trivial? > Or even a short-term solution? So why would you introduce a change that may triger a lot of new complications and incompatibilities? To increase flexibility. I have a multiarch on my amd64 system only because I want to use applications that I can't use or does not have the same functionalities with amd64 (mostly firefox, ooo and mplayer then...). But I'll be happy to have a full amd64 system if only they could provide the same with it. So, as for Pierre, a binary package per multiarch system seems obviously the solution, since a user needs only a given functionalities. Why would you see many binaries installed from the user point of view? with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] For example because one user would like to have the absolute latest version of a certain package while other users are satisfied with the version in stable or testing. Or because you've got scripts that depend on php4 while you've also got scripts that depend on php5. Or because you'd like to compile a binary with libmysqlclient14-dev and then compile a binary with libmysqlclient15-dev.
Re: multiarch status update
#include * Matt Taggart and others [Wed, May 10 2006, 02:00:47AM]: > http://wiki.debian.org/multiarch Looking at all that I have a simple question: do we need a such kind of invasive multiarch integration. There only things I have to use which are not available for native amd64. For this things, we could create "installer" packages which integrate that software and cook the whole dependency chain from i386 Debian packages, by relocating the files and editing the package attributes. This workaround can be created (or is already created) full painless than introducing a whole multiarch system. I agree with people argumenting that sometimes using i386 versions does mean real speedup but I don't believe that this does count. Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Hi all! On Monday 15 May 2006 14:15, Olaf van der Spek wrote: > > this is a dream. This also need that the application is able to deal > > with the fact that it has configuration for the 32 and 64 bits version > > coexisting cleanly. > > True. Did I say that it would be trivial? > Or even a short-term solution? So why would you introduce a change that may triger a lot of new complications and incompatibilities? I have a multiarch on my amd64 system only because I want to use applications that I can't use or does not have the same functionalities with amd64 (mostly firefox, ooo and mplayer then...). But I'll be happy to have a full amd64 system if only they could provide the same with it. So, as for Pierre, a binary package per multiarch system seems obviously the solution, since a user needs only a given functionalities. Why would you see many binaries installed from the user point of view? Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/15/06, Pierre Habouzit <[EMAIL PROTECTED]> wrote: Le Dim 14 Mai 2006 21:11, Olaf van der Spek a écrit : > > - Why would you want to have both types installed simultaneously > > anyway? > > > > For libraries the answer is simple, but multiarch applications > > simply don't seem useful to me. The solution would be to either > > forbid having > > Consider for example 32-bit and 64-bit Firefox with some extensions > only available for 32-bit and others only for 64-bit. this is a dream. This also need that the application is able to deal with the fact that it has configuration for the 32 and 64 bits version coexisting cleanly. True. Did I say that it would be trivial? Or even a short-term solution? given the crap that is firefox configuration, you won't be able to have different lists of plugins for the 32 and 64 bits versions at the same time. Firefox was just an example.
Re: multiarch status update
On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: Bill Allombert <[EMAIL PROTECTED]> writes: > On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote: >> I so far haven't seen any compelling arguments for multiarchifying the >> whole archive including all of */bin. > > Personnally I would favor a new files hierachy that allow every > arch-dependend files to be co-installable. Even if we are not able to > take full advantage of it at once, it seems saner and more forward-looking > than only allowing libraries to be co-installable. This might also make > easier to have this new scheme adopted by other OS. > > Cheers, But would make it totaly incompatible with existing systems. Why do you think there's no compatible solution?
Re: multiarch status update
On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Being able to install multiple versions is some use to multiarch, but > could also be used for other things, such if two packages provide the > same binary (git for example). > Or to install multiple 'version 'numbers' of the same package. The big problem then is when to install multiple versions of a binary? When a dependency or user asks for it explicitly for example. How should the depends decide when that is needed or wanted and when not? Esspecialy when different versions are available per architecture. That depends on the implementation but I don't think it's not solvable. How would programs or user specifiy what binary to call? How would A program would do it via dependency and configuration information. A user would (for example) do it via configuration. users even know which binary is which if they have the same name and both packages are installed on the system? A user could use the full path or 'symlink' the full path to a unique name. Instead of symlinks another more flexible approach could also be used. Just imagine the confusion of a user installing foo (which provides the same binary "foo" as bar) and calling foo gives him bars "foo". Should I imagine that the user has installed bar?
Re: multiarch status update
On 5/15/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: "Olaf van der Spek" <[EMAIL PROTECTED]> writes: > On 5/14/06, Michal Čihař <[EMAIL PROTECTED]> wrote: >> > > The Linux kernel requires a full path for #! scripts. This makes >> > >> > One option would be to improve the Linux kernel. :) >> >> And make scripts incompatible with any other unix kernel? > > No and that's not what I said. I'm quite sure there is a solution that > doesn't break compatibility. Then that solution may not require a change in the kernel and must use '#! /full/path/to/binary'. Meaning: It must be what we use now. Not true. For example, the kernel could be changed to pick the right Python binary if it sees #!/usr/bin/python. Then you have a backwards compatible solution.
Re: multiarch status update
Bill Allombert <[EMAIL PROTECTED]> writes: > On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote: >> I so far haven't seen any compelling arguments for multiarchifying the >> whole archive including all of */bin. > > Personnally I would favor a new files hierachy that allow every > arch-dependend files to be co-installable. Even if we are not able to > take full advantage of it at once, it seems saner and more forward-looking > than only allowing libraries to be co-installable. This might also make > easier to have this new scheme adopted by other OS. > > Cheers, But would make it totaly incompatible with existing systems. The library path is limited to a very few places that can be changed globaly (ld, binutils, gcc) and then the multiarchified binaries will still run on other systems and their binaries will run on multiarch. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Le Dim 14 Mai 2006 21:11, Olaf van der Spek a écrit : > > - Why would you want to have both types installed simultaneously > > anyway? > > > > For libraries the answer is simple, but multiarch applications > > simply don't seem useful to me. The solution would be to either > > forbid having > > Consider for example 32-bit and 64-bit Firefox with some extensions > only available for 32-bit and others only for 64-bit. this is a dream. This also need that the application is able to deal with the fact that it has configuration for the 32 and 64 bits version coexisting cleanly. given the crap that is firefox configuration, you won't be able to have different lists of plugins for the 32 and 64 bits versions at the same time. It's also true for most of the applications that one may like to have in 32 and 64 bits versions at the same time, most of the time, those application cannot have two installed versions without lots of troubles. Moreover, having 32 + 64 bits versions of the programs is terrible in term of user experience. I don't see much gain in having it, and I see a lot of reasons that makes it really awful to deal with: * think of the horror in the X menus, we will have to differenciate 32 and 64 bits versions, * if your $PATH is 20 items long, then your brain explodes when you try to understand why $foo in 32 bits execs $bar in 64 bits when you'd prefer it to run the 32 bits version, * ... I honnestly think that coexisting of 32/64 bits versions is a per package problem, and can be solved with alternatives (e.g. for perl, python, $foo-script-language), with some packages using the legacy /usr/bin/$interpret when they don't care about the arch, or /usr/bin/$interpret.$arch when they need the specific one. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpw1L6UX7DNs.pgp Description: PGP signature
Re: multiarch status update
On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote: > Henning Makholm wrote: > > >In multiarch, the right approach to this particular problem is to > >arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python > >with $arch chosen (somehow) appropriately for a default python > >interpreter. > > Apart from the fact that no multiarch proposals have tried to > multiarchify /usr/bin and /bin, but are rather letting applications for Some multiarch proposals provided non-conflicting path for executables as well. What they failed to do was to allow to install two packages containing the same executable for two different plateforms. > which multiarch makes sense (think gcc) handle this themselves. How ? > I so far haven't seen any compelling arguments for multiarchifying the > whole archive including all of */bin. Personnally I would favor a new files hierachy that allow every arch-dependend files to be co-installable. Even if we are not able to take full advantage of it at once, it seems saner and more forward-looking than only allowing libraries to be co-installable. This might also make easier to have this new scheme adopted by other OS. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Jeremy T. Bouse" <[EMAIL PROTECTED]> writes: > I just felt like interjecting after having been reading up on this > tread. The whole multiarch situation is exactly why my workstation > was re-installed with FC5's x86_64 from the old Debian amd64 > distro. Someday when Debian has multiarch I'll switch it back but > for now all my 64 bit machines are running FC5 because it works a > hell of a lot better than Debian right now. Neither RedHat nor SuSe do have multiarch. Not even close. They have some minimal biarch support that is more based on an accident (or bug) in rpm than anything else and is comparable to ia32-libs and friends. They have more of those libs than debian has but that is mainly a lack of interest on our part. > While there are definitely differences between the packaging > formats it would appear that a solution for this is out there and > from reading the thread sounds like people want to make it more > difficult than it possibly is. Or maybe I'm just seeing that and > it's really that people think it's too difficult so it won't be > worth the effort. Who knows! Looking through my FC5 I can easily > tell the 32-bit libraries as they're the ones installed under > paths like /usr/lib and /lib64 while the 64-bit libraries are the > ones in /usr/lib64 and /lib64. If I run 'file *' while in /usr/bin > I find binaries that are both 64- and 32-bit side-by-side. Granted > most are 64-bit only and only a few are 32-bit only, but there are > a couple that are both in which case most are support binaries and > have a suffix of either -32 or -64 to their names. The ones that > fall into this latter category are things like > gdk-pixbuf-query-loaders, gtk-query-immodules and > pango-querymodules. The nice thing is I have no problem grabbing a > i386 package and installing it or even a 64-bit package that makes > use of 32-bit libraries. What 64bit package can make use of 32bit libraries? 64/32bit clue code would be something mplayer would certainly be intrested in to use w32codes for a 64bit mplayer. > The solution is out there and I think it's probably much simplier > than it's being made out to be if it really becomes a high > priority for Debian. But you can't have i386 and amd64 rpms in your sources.list equivalent and have rpm pull in libraries as needed or pick suitable arch for each binary package or let you pick the architecture for one package. Hell, when you install a i386 rpm you end up with rpm pulling in the 64bit library resulting in a total mess from what I hear. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Olaf van der Spek" <[EMAIL PROTECTED]> writes: > On 5/14/06, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: >> both versions installed, or deal with it via alternatives. They should >> be indistinguishable from a users point of view. > > Being able to install multiple versions is some use to multiarch, but > could also be used for other things, such if two packages provide the > same binary (git for example). > Or to install multiple 'version 'numbers' of the same package. The big problem then is when to install multiple versions of a binary? How should the depends decide when that is needed or wanted and when not? Esspecialy when different versions are available per architecture. How would programs or user specifiy what binary to call? How would users even know which binary is which if they have the same name and both packages are installed on the system? Just imagine the confusion of a user installing foo (which provides the same binary "foo" as bar) and calling foo gives him bars "foo". That is totaly out of the question. Packages that provide the same (by name) binary (or even just file) MUST conflict. period. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes: > On 5/14/06, Olaf van der Spek <[EMAIL PROTECTED]> wrote: >> On 5/13/06, Henning Makholm <[EMAIL PROTECTED]> wrote: >> > sense if one considers a #! program to be something that should have >> > predictable behavior no matter what the user happens to have in his >> > $PATH. >> >> If the independence is a requirement, yes. >> But I don't think it has to be a requirement. >> And I think you can replace the path way with a better solution. > > My question is: > - Why does a python program care whether it's running under a 32 or 64 > bit version? Surely it shouldn't matter? Because it tries to dlopen /usr/i486-linux/lib/foobar/plugin.so, which needs to use the full path. > - Why would you want to have both types installed simultaneously anyway? Only reason is when there are plugins for each arch that the other arch doesn't have (unlikely that amd64 plugins won't be available on i386 for the near future) or when performance differs a lot for programs that don't need the i386 only plugin. > For libraries the answer is simple, but multiarch applications simply > don't seem useful to me. The solution would be to either forbid having > both versions installed, or deal with it via alternatives. They should > be indistinguishable from a users point of view. Hence multiarch never made an attempt of splitting /bin/ directories so far. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Tollef Fog Heen <[EMAIL PROTECTED]> writes: > Henning Makholm wrote: > >> In multiarch, the right approach to this particular problem is to >> arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python >> with $arch chosen (somehow) appropriately for a default python >> interpreter. > > Apart from the fact that no multiarch proposals have tried to > multiarchify /usr/bin and /bin, but are rather letting applications > for which multiarch makes sense (think gcc) handle this themselves. Actualy gcc doesn't handles that at all. Gcc handles the case of multiple gcc that produce code for different architectures (different output). Not different gcc binaries that output for the same architecture. > I so far haven't seen any compelling arguments for multiarchifying the > whole archive including all of */bin. But a lot of reasons not to. > - tfheen MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Olaf van der Spek" <[EMAIL PROTECTED]> writes: > On 5/14/06, Michal ÄihaÅ <[EMAIL PROTECTED]> wrote: >> > > The Linux kernel requires a full path for #! scripts. This makes >> > >> > One option would be to improve the Linux kernel. :) >> >> And make scripts incompatible with any other unix kernel? > > No and that's not what I said. I'm quite sure there is a solution that > doesn't break compatibility. Then that solution may not require a change in the kernel and must use '#! /full/path/to/binary'. Meaning: It must be what we use now. Hey, we are alraedy doing that. Problem solved. :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes: > On Sat, May 13, 2006 at 10:54:57PM +0200, Henning Makholm wrote: >> The Linux kernel requires a full path for #! scripts. This makes >> sense if one considers a #! program to be something that should have >> predictable behavior no matter what the user happens to have in his >> $PATH. > > The standard idiom for this seems to be "#! /usr/bin/env python". > > /* Stienar */ Which is a major portability problem for #!/usr/bin/perl -w The #! syntax only works consistent with up to one argument. Anything further depends on the system. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/14/06, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: On 5/14/06, Olaf van der Spek <[EMAIL PROTECTED]> wrote: > On 5/13/06, Henning Makholm <[EMAIL PROTECTED]> wrote: > > sense if one considers a #! program to be something that should have > > predictable behavior no matter what the user happens to have in his > > $PATH. > > If the independence is a requirement, yes. > But I don't think it has to be a requirement. > And I think you can replace the path way with a better solution. My question is: - Why does a python program care whether it's running under a 32 or 64 bit version? Surely it shouldn't matter? Under a 32-bit version it may be able to use less memory and may perform less. But a good solution to the #! line issue could also be used to select a specific Python version or deal with a Python in another location. - Why would you want to have both types installed simultaneously anyway? For libraries the answer is simple, but multiarch applications simply don't seem useful to me. The solution would be to either forbid having Consider for example 32-bit and 64-bit Firefox with some extensions only available for 32-bit and others only for 64-bit. both versions installed, or deal with it via alternatives. They should be indistinguishable from a users point of view. Being able to install multiple versions is some use to multiarch, but could also be used for other things, such if two packages provide the same binary (git for example). Or to install multiple 'version 'numbers' of the same package.
Re: multiarch status update
On 5/14/06, Olaf van der Spek <[EMAIL PROTECTED]> wrote: On 5/13/06, Henning Makholm <[EMAIL PROTECTED]> wrote: > sense if one considers a #! program to be something that should have > predictable behavior no matter what the user happens to have in his > $PATH. If the independence is a requirement, yes. But I don't think it has to be a requirement. And I think you can replace the path way with a better solution. My question is: - Why does a python program care whether it's running under a 32 or 64 bit version? Surely it shouldn't matter? - Why would you want to have both types installed simultaneously anyway? For libraries the answer is simple, but multiarch applications simply don't seem useful to me. The solution would be to either forbid having both versions installed, or deal with it via alternatives. They should be indistinguishable from a users point of view. -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/
Re: multiarch status update
On 5/14/06, Michal Čihař <[EMAIL PROTECTED]> wrote: > > The Linux kernel requires a full path for #! scripts. This makes > > One option would be to improve the Linux kernel. :) And make scripts incompatible with any other unix kernel? No and that's not what I said. I'm quite sure there is a solution that doesn't break compatibility. > Another option would be to update the #! line at install time with the > right prefix. This would kill MD5 checksums of changed files... True. :(
Re: multiarch status update
Hi On Sun, 14 May 2006 18:32:00 +0200 "Olaf van der Spek" <[EMAIL PROTECTED]> wrote: > On 5/13/06, Henning Makholm <[EMAIL PROTECTED]> wrote: > > The Linux kernel requires a full path for #! scripts. This makes > > One option would be to improve the Linux kernel. :) And make scripts incompatible with any other unix kernel? > Another option would be to update the #! line at install time with the > right prefix. This would kill MD5 checksums of changed files... -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: multiarch status update
On 5/13/06, Henning Makholm <[EMAIL PROTECTED]> wrote: Scripsit "Olaf van der Spek" <[EMAIL PROTECTED]> > Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >> That would be total insanity. Just think about the number of scripts >> with "#!/usr/bin/python" in it that would have to be changed. And how > Shouldn't such hard-coded paths be avoided in the long term (anyway)? The Linux kernel requires a full path for #! scripts. This makes One option would be to improve the Linux kernel. :) Another option would be to update the #! line at install time with the right prefix. sense if one considers a #! program to be something that should have predictable behavior no matter what the user happens to have in his $PATH. If the independence is a requirement, yes. But I don't think it has to be a requirement. And I think you can replace the path way with a better solution. In multiarch, the right approach to this particular problem is to arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python with $arch chosen (somehow) appropriately for a default python interpreter. Such symlinks don't seem to be very flexible, as they're basically system wide.
Re: multiarch status update
Henning Makholm wrote: In multiarch, the right approach to this particular problem is to arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python with $arch chosen (somehow) appropriately for a default python interpreter. Apart from the fact that no multiarch proposals have tried to multiarchify /usr/bin and /bin, but are rather letting applications for which multiarch makes sense (think gcc) handle this themselves. I so far haven't seen any compelling arguments for multiarchifying the whole archive including all of */bin. - tfheen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Sat, May 13, 2006 at 10:54:57PM +0200, Henning Makholm wrote: > The Linux kernel requires a full path for #! scripts. This makes > sense if one considers a #! program to be something that should have > predictable behavior no matter what the user happens to have in his > $PATH. The standard idiom for this seems to be "#! /usr/bin/env python". /* Stienar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Scripsit "Olaf van der Spek" <[EMAIL PROTECTED]> > Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >> That would be total insanity. Just think about the number of scripts >> with "#!/usr/bin/python" in it that would have to be changed. And how > Shouldn't such hard-coded paths be avoided in the long term (anyway)? The Linux kernel requires a full path for #! scripts. This makes sense if one considers a #! program to be something that should have predictable behavior no matter what the user happens to have in his $PATH. In multiarch, the right approach to this particular problem is to arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python with $arch chosen (somehow) appropriately for a default python interpreter. -- Henning Makholm"Detta, sade de, vore rena sanningen; ty de kunde tala sanning lika väl som någon annan, när de bara visste vad det tjänade til." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
I just felt like interjecting after having been reading up on this tread. The whole multiarch situation is exactly why my workstation was re-installed with FC5's x86_64 from the old Debian amd64 distro. Someday when Debian has multiarch I'll switch it back but for now all my 64 bit machines are running FC5 because it works a hell of a lot better than Debian right now. While there are definitely differences between the packaging formats it would appear that a solution for this is out there and from reading the thread sounds like people want to make it more difficult than it possibly is. Or maybe I'm just seeing that and it's really that people think it's too difficult so it won't be worth the effort. Who knows! Looking through my FC5 I can easily tell the 32-bit libraries as they're the ones installed under paths like /usr/lib and /lib64 while the 64-bit libraries are the ones in /usr/lib64 and /lib64. If I run 'file *' while in /usr/bin I find binaries that are both 64- and 32-bit side-by-side. Granted most are 64-bit only and only a few are 32-bit only, but there are a couple that are both in which case most are support binaries and have a suffix of either -32 or -64 to their names. The ones that fall into this latter category are things like gdk-pixbuf-query-loaders, gtk-query-immodules and pango-querymodules. The nice thing is I have no problem grabbing a i386 package and installing it or even a 64-bit package that makes use of 32-bit libraries. The solution is out there and I think it's probably much simplier than it's being made out to be if it really becomes a high priority for Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/13/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: That would be total insanity. Just think about the number of scripts with "#!/usr/bin/python" in it that would have to be changed. And how Shouldn't such hard-coded paths be avoided in the long term (anyway)? would you even change them to pick the right architectures python? Same for sh, perl, javal, ocaml, . I think the dependency should be considered a configuration issue. Use #!python instead and have the 'environment' pick the right binary target.
Re: multiarch status update
Thiemo Seufer <[EMAIL PROTECTED]> writes: > I think we need a canonical ABI-OS (or ABI-KERNEL-OS ?) table which > provides mappings for multiarch-sensitive programs. I have dpkg-multiarch for that and other things like cflags, ldflags, libdir and the like. dpkg-multiarch is used just like dpkg-architecture just that it has different variables and an extra parameter to specifiy the target ABI. E.g. asking for CFLAGS for target ABI i486-linux-gnu on x86_64 will give you "-m32". MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
[EMAIL PROTECTED] writes:
> There is yet another issue with the $arch portion of the canonical system
> name: chips which are upgrades of other chips. For instance, Fedora will
> give you 'i686', while Debian will give you 'i486'. This will (and should)
> result in two different directories -- different multiarch variants.
> However, programs compiled for i486 will run on i686.
>
> This raises fairly complex program interpreter issues for the simplest case
> (intercompatibility between Debian and RedHat on x86).
> Software must expect to be able to install to the i486-linux-gnu directories
> and function immediately, even on a "natively" i686-linux-gnu system.
> Likewise software should be able to install to the i686-linux-gnu directories
> and function immediately if the chip is actually an i686, even on an
> i486-linux-gnu system.
A proposed solution to this is pretty simple:
dpkg/apt can check all archs compatible with the cpu (and enabled in
the config). That means on i686 it can check i486, i585 and i686.
When installing dpkg/apt look at the ABI of each package instead of
the architecture and i[456]86 are all ia32. Those package naturaly
conflict and only one of them can be installed in parallel.
Whether you use i486-linux-gnu or i686-linux-gnu for i686 optimized
packages remains open but it is a simple change for the ld to include
that dir. If i686-linux-gnu is consistently used for i686 optimized
packages then one could even allow installing i486 and i686 flavours
of a package and have any of them suffice for a depends.
> Now, this is in fact trivial with the current non-multiarch situation. We
> must be careful not to break it with multiarch! Perhaps an "x86 annexe" to
> the specifications would help?
>
> I *believe* that this can be handled as follows:
> (1) Specify a list of arch-os pairs which are ABI-compatible
> (i486-linux-gnu, i586-linux-gnu, i686-linux-gnu perhaps)
> (2) Rework the program interpreter to search through all three arch-os pairs,
> starting with the "highest" one which the actual chip supports.
>
> However, this all seems to duplicate the existing functionality with
> /usr/lib/tls/{i486, i586, i686}. But perhaps it should be considered
> to be replacing that functionality? That seems like a wise way to go,
> actually.
That support is arch specific and varies widely between archs. It also
goes into "minor" differences within one arch, e.g. i686 is available
with and without cmov instruction.
> If not, it may be simpler to just specify outright that all x86 machines
> should use i486-linux-gnu, NOT i686-linux-gnu, regardless of what
> config.guess thinks, and that libraries compiled for the higher chips
> should use the subdirectories.
>
> Please consider the x86 intercompatibility case before making any final
> proposals. It's very important. :-)
>
> --Nathanael Nerode
Given that ld already covers the subelties of different i*86
architectures many people feel it is best to leave it there and just
put all i*86 in i486. After all, they are all one ABI and that is what
we actualy sort for.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Joe Smith" <[EMAIL PROTECTED]> writes: > "Daniel Ruoso" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >>Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu: >>> On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote: >>> > Why would that not fly? >>> > Both versions of the arch-independent package could be installed at >>> > the same time. >>> /usr/share/foo/bar can't point to two different files at the same time, >>> so you can't install multiple package versions containing >>> incompatible /usr/share/foo/bar files. >>> The only way to support your proposal would be to kill the concept of >>> arch-independent packages and make everything arch-dependent. >> >>And what if dpkg knows about it and handle arch-independant packages in >>a different way? >> >>In fact, if the system is multiarch, dpkg should have a centralized list >>of which packages are installed for each architecture and which packages >>are installed for arch: all... >> >>But there's still the problem of arch-independant files inside >>arch-dependant files (maybe an arch-dependant package should not include >>arch-indenpendant files at all)... > > The problem is when foo [i386] depends on bar [all] 1.0, > but foo [amd64] depends on bar [all] 2.0. > > There is simply no good way to have bar [all] 1.0 and bar [all] 2.0 > installed, > so foo [i386] and foo [amd64] cannot both be installed. That can not happen in a release. Only one bar can be in testing and then one of the foos would be uninstallable. Britney prevents that. MfG Goswin PS: I will (and does already anyway) happen all the time in sid depending on the speed of buildds. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Olaf van der Spek" <[EMAIL PROTECTED]> writes: > On 5/10/06, Matt Taggart and others <[EMAIL PROTECTED]> wrote: >> For a couple years now a few of us have been talking about an idea called >> "multiarch". This is a way to seamlessly allow support for multiple different >> binary targets on the same system, for example running both i386-linux-gnu >> and >> amd64-linux-gnu binaries on the same system (many other working combinations >> exist as well). I have created a new page in the wiki to track info and >> status > > Does it also allow completely arbitrary combinations to be installed? There are 3 cases that concern multiarch: 1) no Multiarch line (all old packages) Only one architecture of this package can be installed and any depends on this package must match the ABI. This keeps all existing debs working as they work now. It is the only save assumption. 2) Multiarch: no This package does not need to have multiple architectures installed (and nearly always can't). That means any depends on it do not involve the ABI. No library is in this package and any architecture will fullfill the depends for any other. Basicaly this means this is a binary package with only a command line interface that is architecture independent. 3) Multiarch: yes This package can have multiple architectures installed and any depending package must have the matching ABI installed for it. Any library package has to set this if they want to support multiarch. All the essential, required and base libraries need to support this as a minimum. X, gnome and kde almost certainly need this too for the users benefit. More obscure libs can probably get away with sticking to option 1. >> * allow for seamless large ABI transitions >> * allow users to smoothly migrate from one arch to another >> * do things like "partial architectures" so that we can add weird >> processor variants without needing to add an entire new port to the >> pool/mirrors >> * better assimilate the *BSD kernels and userspaces >> * better support non-monopoly archs, since they may be able to run bits >> for other archs >> * maybe even to do stuff like use non-native archs (with support for >> other binary targets) to build native bits (m68k emulator on >> superfast amd64?). >> * other cool stuff > > Does it also allow multiple versions of the same package to be > installed at the same time? > For example, multiple minor versions or multiple major versions? Only if they also differ in the architecture/abi. This won't remove the need to rename libfoo1 to libfoo2 on ABI changes. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Adam Borowski <[EMAIL PROTECTED]> writes: > On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote: >> On the other hand, if we continue that thought process we could end up >> with all headers and libraries in /usr/share/, which is absurd. > > Why? This is exactly what's beautiful, especially if EVERYTHING ends up in > /usr/share/ at one day, at which point /share/ will be redundant and the FHS > will change. > >> Indeed, the current proposal almost seems to be reversing this. >> >Non-target specific libraries and header files remain in $prefix/lib and >> >$prefix/include. >> It seems to me that libraries and headers that are not target specific are >> supposed to go in /usr/share. >> That is because if they are not target specific they are most certainly >> cross-platform. Maybe they should. The amount of software thatr assumes /usr/include is being used might be to big of a problem though to get that changed any time soon. > I remember a lab that consisted mostly of SGI Indy boxes, a SunOS server, > some O2 and a stray Linux or two. The common problem was incompatibility of > binaries: things compiled on an Indy worked on the Indies and O2, but things > compiled on O2 were incompatible with Indy. Exactly the same thing as > i386->i486->i586->i686->amd64. > > Now, imagine that /usr/bin is split this way: > /usr/bin (perl, bash) > /usr/bin/indy (binaries) > /usr/bin/o2 (binaries) > /usr/bin/sun (binaries) [1] > Can you see what I mean? By just having different PATHs, everything would > be completely transparent. And the multiarch would take care of all > libraries and headers. That would be total insanity. Just think about the number of scripts with "#!/usr/bin/python" in it that would have to be changed. And how would you even change them to pick the right architectures python? Same for sh, perl, javal, ocaml, . Also depending on PATH to be specific for each arch would be a violation of debian policy somewhere. >> Hm... This entire concept seems messy. It seems that processors that >> support multiple architectures, as well as cross compilition are begining >> to blur the line between /usr and /usr/share. > > It's not "messy", it's plain awesome. And if the line gets blurred into > oblivion, it will be a reason for joy. No solution for multiarch I've seen so far has changed anything for cross compiling though. That is quite a different story. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Thu, May 11, 2006 at 06:12:42PM -0300, Daniel Ruoso wrote: > And what if dpkg knows about it and handle arch-independant packages in > a different way? There is nothing dpkg can do. Package-1.0 has a hardcoded reference to /usr/share/foo/bar (provided by some other package) and expects it to be version 1. Package-2.0 has a hardcoded reference to /usr/share/foo/bar and expects it to be version 2 which is not compatible with version 1. If you install package-1.0 and package-2.0 simultaneously one of them _will_ break. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Daniel Ruoso" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu: On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote: > Why would that not fly? > Both versions of the arch-independent package could be installed at > the same time. /usr/share/foo/bar can't point to two different files at the same time, so you can't install multiple package versions containing incompatible /usr/share/foo/bar files. The only way to support your proposal would be to kill the concept of arch-independent packages and make everything arch-dependent. And what if dpkg knows about it and handle arch-independant packages in a different way? In fact, if the system is multiarch, dpkg should have a centralized list of which packages are installed for each architecture and which packages are installed for arch: all... But there's still the problem of arch-independant files inside arch-dependant files (maybe an arch-dependant package should not include arch-indenpendant files at all)... The problem is when foo [i386] depends on bar [all] 1.0, but foo [amd64] depends on bar [all] 2.0. There is simply no good way to have bar [all] 1.0 and bar [all] 2.0 installed, so foo [i386] and foo [amd64] cannot both be installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Adam Borowski" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote: On the other hand, if we continue that thought process we could end up with all headers and libraries in /usr/share/, which is absurd. Why? This is exactly what's beautiful, especially if EVERYTHING ends up in /usr/share/ at one day, at which point /share/ will be redundant and the FHS will change. That will be hard, a /usr/share to /usr symlink would likely end up part of that transition, and poorly written software could ave some trouble with that. Hm... This entire concept seems messy. It seems that processors that support multiple architectures, as well as cross compilition are begining to blur the line between /usr and /usr/share. It's not "messy", it's plain awesome. And if the line gets blurred into oblivion, it will be a reason for joy. Indeed. I was speeking about the transition being messy, not the final result. I take it that you are interested in a multi-arch solution for binaries, which the "upstream" proposal currently does not cover. Overall the idea seems good. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote: > On the other hand, if we continue that thought process we could end up > with all headers and libraries in /usr/share/, which is absurd. Why? This is exactly what's beautiful, especially if EVERYTHING ends up in /usr/share/ at one day, at which point /share/ will be redundant and the FHS will change. > Indeed, the current proposal almost seems to be reversing this. > >Non-target specific libraries and header files remain in $prefix/lib and > >$prefix/include. > It seems to me that libraries and headers that are not target specific are > supposed to go in /usr/share. > That is because if they are not target specific they are most certainly > cross-platform. I remember a lab that consisted mostly of SGI Indy boxes, a SunOS server, some O2 and a stray Linux or two. The common problem was incompatibility of binaries: things compiled on an Indy worked on the Indies and O2, but things compiled on O2 were incompatible with Indy. Exactly the same thing as i386->i486->i586->i686->amd64. Now, imagine that /usr/bin is split this way: /usr/bin (perl, bash) /usr/bin/indy (binaries) /usr/bin/o2 (binaries) /usr/bin/sun (binaries) [1] Can you see what I mean? By just having different PATHs, everything would be completely transparent. And the multiarch would take care of all libraries and headers. > Hm... This entire concept seems messy. It seems that processors that > support multiple architectures, as well as cross compilition are begining > to blur the line between /usr and /usr/share. It's not "messy", it's plain awesome. And if the line gets blurred into oblivion, it will be a reason for joy. [1] Ok, ok. I'm stretching it a bit, as SunOS was a different beast than IRIX. But if all boxes are Debian... Cheers. -- 1KB // Rule #6: If violence wasn't your last resort, // you failed to resort to enough of it. // - The Seven Habits of Highly Effective Pirates -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu: > On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote: > > Why would that not fly? > > Both versions of the arch-independent package could be installed at > > the same time. > /usr/share/foo/bar can't point to two different files at the same time, > so you can't install multiple package versions containing > incompatible /usr/share/foo/bar files. > The only way to support your proposal would be to kill the concept of > arch-independent packages and make everything arch-dependent. And what if dpkg knows about it and handle arch-independant packages in a different way? In fact, if the system is multiarch, dpkg should have a centralized list of which packages are installed for each architecture and which packages are installed for arch: all... But there's still the problem of arch-independant files inside arch-dependant files (maybe an arch-dependant package should not include arch-indenpendant files at all)... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
[EMAIL PROTECTED] wrote: > >I have created a new page in the wiki to track info and status > > > > http://wiki.debian.org/multiarch > > I looked at the "upstream standards proposal": > http://lackof.org/taggart/hacking/multiarch/ > > It's good. > I am particularly pleased by the specification: > > "The terms arch and os represent the Architecture and Operating System > as defined and provided by config.guess." > > It is crucial that this naming be entirely standardized. This *should* > be sufficient. Is it sufficient? Cases where it would not be sufficient > would be the following: > > (1) Cases where config.guess reports the same name for functionally different > systems, such as the two MIPS ABIs. This should be considered a bug in > config.guess, plain and simple. To expand a bit on this, I don't think config.guess is sufficient to handle those cases. E.g. for a MIPS system with 64bit kernel, config.guess will return mips64el-unknown-linux-gnu even when there's only a (little endian) O32 userland installed, but for a 32bit kernel it will be mipsel-unknown-linux-gnu unless the call is prefixed with linux32, which changes the uname, and thus the config.guess output. The endianness is guessed from the defaults of the system compiler (the first cc in $PATH), which is a) not necessarily available, and b) supposed to be exchangable in a full multiarch environment. What's worse, "mips64" is a rather entrenched term with inconsistent meanings which cover both the N32 and N64 ABI. A "fix" to config.guess would AFAICS require to specify a multiarch mode, which changes the output to, say, mipsn32el-unknown-linux-gnu for N32 and to mipsn64-unknown-linux-gnu for N64 (that still doesn't answer the question which ABI would be the "native" one). But in that case the config.guess can't be the canonical source of information any more. This is not only MIPS-specific, a similiar problem arises e.g. for a ILP32 ABI for x86_64. I think we need a canonical ABI-OS (or ABI-KERNEL-OS ?) table which provides mappings for multiarch-sensitive programs. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
"Matt Taggart and others" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Hi debian-devel, For a couple years now a few of us have been talking about an idea called "multiarch". This is a way to seamlessly allow support for multiple different binary targets on the same system, for example running both i386-linux-gnu and amd64-linux-gnu binaries on the same system (many other working combinations exist as well). I have created a new page in the wiki to track info and status My thoughts on a few multi-arch concepts. It is important to differentiate between the types of non-native files. There are files that are not native, but are intended to be used by native programs targeting the non-native arch. These include things like arch-specific header files. It almost seems like these should be put in /usr/share/include/$arch-$os/. (where $arch and $os represent the target arch) That is because headers for cross compiling are normally dependent on the target arch, but not the host arch. On the other hand, if we continue that thought process we could end up with all headers and libraries in /usr/share/, which is absurd. Indeed, the current proposal almost seems to be reversing this. Non-target specific libraries and header files remain in $prefix/lib and $prefix/include. It seems to me that libraries and headers that are not target specific are supposed to go in /usr/share. That is because if they are not target specific they are most certainly cross-platform. Hm... This entire concept seems messy. It seems that processors that support multiple architectures, as well as cross compilition are begining to blur the line between /usr and /usr/share. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On Thu, 11 May 2006, [EMAIL PROTECTED] wrote: > "The terms arch and os represent the Architecture and Operating System > as defined and provided by config.guess." Well, config.sub is the one whose function is to provide canonical names, config.guess might not do so for one reason or another (but it usually does provide canonical names, at least when it can). I'd say "config.sub $(config.guess)" is better than just config.guess. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
>I have created a new page in the wiki to track info and status
>
> http://wiki.debian.org/multiarch
I looked at the "upstream standards proposal":
http://lackof.org/taggart/hacking/multiarch/
It's good.
I am particularly pleased by the specification:
"The terms arch and os represent the Architecture and Operating System
as defined and provided by config.guess."
It is crucial that this naming be entirely standardized. This *should*
be sufficient. Is it sufficient? Cases where it would not be sufficient
would be the following:
(1) Cases where config.guess reports the same name for functionally different
systems, such as the two MIPS ABIs. This should be considered a bug in
config.guess, plain and simple.
(2) Cases where config.guess gives noncanonical results. This should not
happen, and if it does it's a bug in config.guess.
(3) Cases where the *manufacturer name* is the sole discriminator between
two functionally different systems. While this *is* the case for some legacy
UNIX systems, I believe it is not the case for any system which might consider
using the FHS or multiarch, or indeed for any common system, so this is
probably not important. However, it could be avoided by simply using the
full canonical system name. However, there are arguments against that,
notably the use of the 'manufacturer' slot in unreliable and inconsistent ways
by Linux distribution vendors, despite no real platform difference.
(4) There is an ambiguity in the specification. config.sub notes:
# The goal of this file is to map all the various variations of a given
# machine specification into a single specification in the form:
# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
# or in some cases, the newer four-part form:
# CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
I believe that when it is the output of config.guess, the
KERNEL-OPERATING_SYSTEM should be considered the $os portion in a
multiarch implementation. This will be necessary to discriminate
between different systems. This would be the natural result of the
naive implementation (which doesn't consider the existence of four-part
canonical system names) anyway.
(5) config.guess has been known to vary its output from system to system
when perhaps it shouldn't. :-) It will be necessary to standardize the
canonical system names for multiarch in this case: it is crucial that we not
have (for instance) i486-linux and i486-linux-gnu directories floating around
separately. Accordingly, I suggest that the upstream proposals should
*specify* the expected $arch-$os results from config.guess for the common,
existing platforms.
-
There is yet another issue with the $arch portion of the canonical system
name: chips which are upgrades of other chips. For instance, Fedora will
give you 'i686', while Debian will give you 'i486'. This will (and should)
result in two different directories -- different multiarch variants.
However, programs compiled for i486 will run on i686.
This raises fairly complex program interpreter issues for the simplest case
(intercompatibility between Debian and RedHat on x86).
Software must expect to be able to install to the i486-linux-gnu directories
and function immediately, even on a "natively" i686-linux-gnu system.
Likewise software should be able to install to the i686-linux-gnu directories
and function immediately if the chip is actually an i686, even on an
i486-linux-gnu system.
Now, this is in fact trivial with the current non-multiarch situation. We
must be careful not to break it with multiarch! Perhaps an "x86 annexe" to
the specifications would help?
I *believe* that this can be handled as follows:
(1) Specify a list of arch-os pairs which are ABI-compatible
(i486-linux-gnu, i586-linux-gnu, i686-linux-gnu perhaps)
(2) Rework the program interpreter to search through all three arch-os pairs,
starting with the "highest" one which the actual chip supports.
However, this all seems to duplicate the existing functionality with
/usr/lib/tls/{i486, i586, i686}. But perhaps it should be considered
to be replacing that functionality? That seems like a wise way to go,
actually.
If not, it may be simpler to just specify outright that all x86 machines
should use i486-linux-gnu, NOT i686-linux-gnu, regardless of what
config.guess thinks, and that libraries compiled for the higher chips
should use the subdirectories.
Please consider the x86 intercompatibility case before making any final
proposals. It's very important. :-)
--Nathanael Nerode
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/11/06, Gabor Gombas <[EMAIL PROTECTED]> wrote: On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote: > Why would that not fly? > Both versions of the arch-independent package could be installed at > the same time. /usr/share/foo/bar can't point to two different files at the same time, so you can't install multiple package versions containing incompatible /usr/share/foo/bar files. The only way to support your proposal would be to kill the concept of I think there are much more ways to implement it. :) But indeed, having all packages put files in a single directory won't work. But that approach is resulting in some problems already today. arch-independent packages and make everything arch-dependent. But that would be a _HUGE_ waste of resources (/usr/share takes about half the size of the /usr partition here). It's not worth it.
Re: multiarch status update
On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote: > Why would that not fly? > Both versions of the arch-independent package could be installed at > the same time. /usr/share/foo/bar can't point to two different files at the same time, so you can't install multiple package versions containing incompatible /usr/share/foo/bar files. The only way to support your proposal would be to kill the concept of arch-independent packages and make everything arch-dependent. But that would be a _HUGE_ waste of resources (/usr/share takes about half the size of the /usr partition here). It's not worth it. 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 status update
On 5/10/06, Olaf van der Spek <[EMAIL PROTECTED]> wrote: On 5/10/06, Matt Taggart <[EMAIL PROTECTED]> wrote: > > Does it also allow multiple versions of the same package to be > > installed at the same time? > > For example, multiple minor versions or multiple major versions? > > Read the papers listed in the wiki. The short answer is no, same as it is > today with single-arch. As explained in the papers, trying to do anything else > results in a complex dependency nightmare. That's a shame, as I think a lot of the infrastructure required for multiple architectures overlaps with that required for multiple versions. You've been able to install multiple versions of the same package for a long time, just we give each package a new name. Libraries are the obvious example but you can install multiple versions of postgresql simultaneously. It's not rocket science, just most people don't consider it worth the effort. In any case, I don't think any of this is going to handle multiple architechtures simultaneously magically. It's more like each arch get given a namespace and everything is carefully designed to stop the namespaces conflicting. TANSTAAFL. -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/
Re: multiarch status update
On 5/10/06, Matt Taggart <[EMAIL PROTECTED]> wrote: > Does it also allow multiple versions of the same package to be > installed at the same time? > For example, multiple minor versions or multiple major versions? Read the papers listed in the wiki. The short answer is no, same as it is today with single-arch. As explained in the papers, trying to do anything else results in a complex dependency nightmare. That's a shame, as I think a lot of the infrastructure required for multiple architectures overlaps with that required for multiple versions.
Re: multiarch status update
"Olaf van der Spek" writes... > Does it also allow completely arbitrary combinations to be installed? We're not sure of this implementation detail yet. But I think... By default your system won't be multiarch, but the sysadmin can turn on combinations. The config file for doing this will have entries for known working combinations, but nothing will prevent you from adding your own combination (because maybe you are developing support for that combination). > Does it also allow multiple versions of the same package to be > installed at the same time? > For example, multiple minor versions or multiple major versions? Read the papers listed in the wiki. The short answer is no, same as it is today with single-arch. As explained in the papers, trying to do anything else results in a complex dependency nightmare. -- Matt Taggart [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/10/06, Gabor Gombas <[EMAIL PROTECTED]> wrote: On Wed, May 10, 2006 at 02:54:23PM +0200, Olaf van der Spek wrote: > Does it also allow multiple versions of the same package to be > installed at the same time? > For example, multiple minor versions or multiple major versions? I think that's not going to fly. Just think about the different arch-dependent packages depending on incompatible versions of an arch-independent package. Why would that not fly? Both versions of the arch-independent package could be installed at the same time.
Re: multiarch status update
On Wed, May 10, 2006 at 02:54:23PM +0200, Olaf van der Spek wrote: > Does it also allow multiple versions of the same package to be > installed at the same time? > For example, multiple minor versions or multiple major versions? I think that's not going to fly. Just think about the different arch-dependent packages depending on incompatible versions of an arch-independent package. 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 status update
On 5/10/06, Matt Taggart and others <[EMAIL PROTECTED]> wrote: For a couple years now a few of us have been talking about an idea called "multiarch". This is a way to seamlessly allow support for multiple different binary targets on the same system, for example running both i386-linux-gnu and amd64-linux-gnu binaries on the same system (many other working combinations exist as well). I have created a new page in the wiki to track info and status Does it also allow completely arbitrary combinations to be installed? * allow for seamless large ABI transitions * allow users to smoothly migrate from one arch to another * do things like "partial architectures" so that we can add weird processor variants without needing to add an entire new port to the pool/mirrors * better assimilate the *BSD kernels and userspaces * better support non-monopoly archs, since they may be able to run bits for other archs * maybe even to do stuff like use non-native archs (with support for other binary targets) to build native bits (m68k emulator on superfast amd64?). * other cool stuff Does it also allow multiple versions of the same package to be installed at the same time? For example, multiple minor versions or multiple major versions?
Re: multiarch status update
On Wed, 2006-05-10 at 02:00 -0700, Matt Taggart and others wrote: > Hi debian-devel, > > For a couple years now a few of us have been talking about an idea called > "multiarch". This is a way to seamlessly allow support for multiple different > binary targets on the same system, for example running both i386-linux-gnu > and > amd64-linux-gnu binaries on the same system (many other working combinations > exist as well). I have created a new page in the wiki to track info and status > > We think multiarch can be implemented with minimal disruption to unstable, > most changes won't effect "single-arch" type systems at all. We'd like to > start working on implementing it, but before we do we wanted to get feedback, > concerns, recommendations, volunteers :), etc. This is a big undertaking and > we're going to need everyone's help to make it happen. Please reply. > I'd prefer to have done it yesterday. I got to know about this because of the possibility to use scratchbox2 with it in a way that you can easily cross compile for any target without a seperated build environment. Also it will ease the use of dpkg-cross a great lot. I think a lot of people don't trust in this can actually work and I'd like to see an actual proof. I definately want to help with this. Jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
multiarch status update
Hi debian-devel, For a couple years now a few of us have been talking about an idea called "multiarch". This is a way to seamlessly allow support for multiple different binary targets on the same system, for example running both i386-linux-gnu and amd64-linux-gnu binaries on the same system (many other working combinations exist as well). I have created a new page in the wiki to track info and status http://wiki.debian.org/multiarch Recently HP and Canonical Ltd. have been looking into possible implementation strategies and this has resulted in the following report http://multiarch.alioth.debian.org/multiarch-hp-report.pdf One of the things that came out of that report is that implementing multiarch would be much easier if we had a few enhancements in the package manager. This prompted Scott James Remnant to start working on a "dpkg 2.0" design document. That has been sent to the debian-dpkg list and is available at http://lists.debian.org/debian-dpkg/2006/05/msg00022.html (please direct any followup about dpkg there) Multiarch will allow Debian to * better support systems that can run multiple binary targets, like i386 on amd64, i386 on ia64. * better support MMX/SSE/Altivec/etc tuned packages * allow for seamless large ABI transitions * allow users to smoothly migrate from one arch to another * do things like "partial architectures" so that we can add weird processor variants without needing to add an entire new port to the pool/mirrors * better assimilate the *BSD kernels and userspaces * better support non-monopoly archs, since they may be able to run bits for other archs * maybe even to do stuff like use non-native archs (with support for other binary targets) to build native bits (m68k emulator on superfast amd64?). * other cool stuff We think multiarch can be implemented with minimal disruption to unstable, most changes won't effect "single-arch" type systems at all. We'd like to start working on implementing it, but before we do we wanted to get feedback, concerns, recommendations, volunteers :), etc. This is a big undertaking and we're going to need everyone's help to make it happen. Please reply. Thanks, -- Tollef Fog Heen <[EMAIL PROTECTED]> dann frazier <[EMAIL PROTECTED]> Lamont Jones <[EMAIL PROTECTED]> Scott James Remnant <[EMAIL PROTECTED]> Matt Taggart <[EMAIL PROTECTED]> Matt Zimmerman <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
