Re: Multiarch and idea for improved diversions and alternatives handling
Neil Williams [EMAIL PROTECTED] writes: On Fri, 2008-07-04 at 08:33 +0200, Tollef Fog Heen wrote: * Neil Williams | Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all | when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire | package under that, as we do with dpkg-cross currently: How would you then handle libraries that go in /lib? (Apart from the fact that I think just using a subdirectory of /usr/lib is much neater than random subdirectories in /usr. /lib/ /arm-linux-gnu/lib/ (did I miss that bit?) A single subdirectory of /usr is, IMHO, neater than a subdirectory of /usr/include and /usr/lib/. It would also mean less changes for those who are currently using multiple architectures on one system for the purposes of cross building. I wouldn't want to go the whole hog though and have /arm-linux-gnu/usr/lib /arm-linux-gnu/lib because that would be ugly, at least to me. | /usr/include/ | /usr/arm-linux-gnu/include/ Please note that the initial goal of multiarch at least has been just running of packages from foreign architectures. Not building them. True but the current usage of these mechanisms is in cross-building so sometimes the results of having to do something without major changes elsewhere can be helpful in designing the subsequent mechanism. The current mechanism is a total mess and needs to be thrown out and done right in any case. binutils on amd64 uses /usr/i386-linux-gnu/lib while i386 uses /usr/i486-linux-gnu/lib. So cross-building will fail there anyway. It also misses /i486-linux-gnu/lib making several core libraries go missing. Not to mention that multilib gcc does not provide the cross compiler binaries for the other supported archs, i.e. i486-linux-gnu-gcc on amd64. Further those directories are totaly wrong when compiling code for e.g. uclibc. The binutils upstream has further decided that it is not binutils place to support multiarch directories. That is a job of the compiler. As such binutils should be stoped from blindly adding the (wrong) cross-compile dir and gcc should add the right directories. So no matter what actual path you pick there has to be exactly the same change. Both binutils and gcc need adapting. | multiarch could even add: | /usr/share/ | /usr/arm-linux-gnu/share Pardon my language, but this is crack. The point of /usr/share is you can share it between systems. If you go down this route, just use a chroot and some wrapper scripts to bounce between them instead. It was only a suggestion for /usr/share - it was an alternative to renaming the package to get a different directory in /usr/share/ as the current tools do. Until all suitable packages have things like translations separated out into TDebs and other things like images in a -data or -common package instead of being packaged along with the architecture-dependent binaries, conflicts will occur if /usr/share is used as intended. Then you could not just share /usr/share via nfs but would have to share all the multiarch share dirs. bad bad bad. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch and idea for improved diversions and alternatives handling
* Neil Williams (Please respect my Mail-Followup-To and my Mail-Copies-To: never) | On Fri, 2008-07-04 at 08:33 +0200, Tollef Fog Heen wrote: | | How would you then handle libraries that go in /lib? (Apart from the | fact that I think just using a subdirectory of /usr/lib is much neater | than random subdirectories in /usr. | | /lib/ | /arm-linux-gnu/lib/ | | (did I miss that bit?) Yes. | A single subdirectory of /usr is, IMHO, neater than a subdirectory | of /usr/include and /usr/lib/. It would be a subdirectory of / as well. | It would also mean less changes for those who are currently using | multiple architectures on one system for the purposes of cross | building. I wouldn't want to go the whole hog though and have | /arm-linux-gnu/usr/lib /arm-linux-gnu/lib because that would be | ugly, at least to me. I think it'd be about as ugly as having /$triplet anyway. | | /usr/include/ | | /usr/arm-linux-gnu/include/ | | Please note that the initial goal of multiarch at least has been just | running of packages from foreign architectures. Not building them. | | True but the current usage of these mechanisms is in cross-building so | sometimes the results of having to do something without major changes | elsewhere can be helpful in designing the subsequent mechanism. Part of the point of multiarch is we don't actually need to make major changes. We need to do some fairly localised changes. | | multiarch could even add: | | /usr/share/ | | /usr/arm-linux-gnu/share | | Pardon my language, but this is crack. The point of /usr/share is you | can share it between systems. If you go down this route, just use a | chroot and some wrapper scripts to bounce between them instead. | | It was only a suggestion for /usr/share - it was an alternative to | renaming the package to get a different directory in /usr/share/ as the | current tools do. Until all suitable packages have things like | translations separated out into TDebs and other things like images in a | -data or -common package instead of being packaged along with the | architecture-dependent binaries, conflicts will occur if /usr/share is | used as intended. Or we could get the file exclusion branch in dpkg applied and add support for excluding files based on the arch of the package being installed. Voila, no problems with file conflicts in /usr/share. | I don't believe anybody has suggested using just /usr/lib/i386, but | rather /usr/lib/i486-linux-gnu? | | OK - as I said, my connection has been flaky and I might have missed | that bit. This bit has been public and on the table at least since I wrote my master thesis in 2005. :-P I don't think anybody has suggested anything else since then. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch and idea for improved diversions and alternatives handling
Neil Williams [EMAIL PROTECTED] writes: On Tue, 2008-07-01 at 18:44 +0200, Goswin von Brederlow wrote: James Vega [EMAIL PROTECTED] writes: On Sat, Jun 28, 2008 at 02:03:05AM -0700, Steve Langasek wrote: So if we allow multiple packages to be installed at the same time which divert the same file, then I think we have another case for wanting to continue supporting an optional diversion target - or at least for not using .diverted by default, since we wouldn't want diversions from multiple packages to collide. Maybe .diverted-$package, then? (My internet connection has been very flaky since this thread started and I have only been able to post intermittently so apologies if this appears to be late or out-of-sync with other posts.) Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire package under that, as we do with dpkg-cross currently: /usr/lib/ /usr/arm-linux-gnu/lib/ /usr/include/ /usr/arm-linux-gnu/include/ multiarch could even add: /usr/share/ /usr/arm-linux-gnu/share Because it pollutes top level directories, namely / and /usr. Think how it will look with 12 abis coexisting. People felt that putting the dirs below /lib/, /usr/lib/ and /usr/include/ would be less invasive. But algorithmically it is all the same. None of the problems change in any way by using one or the other. This adds only one new directory, it keeps the main contents of the package in a single location (making it easier to manage and parse things like dpkg -L) and it means less changes for existing packages that use these paths already. It also means no need for extra diversions at all, no need for Replaces: and no headaches when removing the multiarch vs removing the primary package etc. I think you are mixing things up here. The problem where diversions or replaces where thought about in multiarch is for /usr/share/doc/package/copyright and changelog. Policy dictates they exist and where they have to exist and that becomes a problem. On the other hand the RFC for diversion and alternative handling had nothing to do with multiarch at all and is a totaly seperate line of thought. BTW I think it is a mistake to want to use /usr/lib/i386/ when it is entirely possible that multiarch users will actually need the full triplet - think about hurd or kfreebsd as multiarch packages. Nobody wants to use /usr/lib/i386/. It was always the triplet. There are two use cases to consider regarding multiple packages and diversions. 1) Multiple packages installing a file that has been diverted. Currently, there is only one divert to filename so you'll end up losing data once the second diverted file is installed. This could be alleviated by instead basing the divert to filename on the package which contains the file being diverted (as you suggest above). There's still the problem of what to do when the package providing the diversion is uninstalled as now you have conflicting packages. Actually, you already had conflicting packages that just weren't affected yet because of the diversion, which leads to 2). If the multiarch package can be installed alongside the primary without any conflicts by using /usr/$triplet instead, then the need for the diversion and consequent hacks goes away entirely. Again nothing to do with multiarch. This is about unrelated packages having conflicting files and one diverting the other(s). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch and idea for improved diversions and alternatives handling
* Neil Williams | Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all | when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire | package under that, as we do with dpkg-cross currently: How would you then handle libraries that go in /lib? (Apart from the fact that I think just using a subdirectory of /usr/lib is much neater than random subdirectories in /usr. | /usr/include/ | /usr/arm-linux-gnu/include/ Please note that the initial goal of multiarch at least has been just running of packages from foreign architectures. Not building them. | multiarch could even add: | /usr/share/ | /usr/arm-linux-gnu/share Pardon my language, but this is crack. The point of /usr/share is you can share it between systems. If you go down this route, just use a chroot and some wrapper scripts to bounce between them instead. [...] | BTW I think it is a mistake to want to use /usr/lib/i386/ when it is | entirely possible that multiarch users will actually need the full | triplet - think about hurd or kfreebsd as multiarch packages. I don't believe anybody has suggested using just /usr/lib/i386, but rather /usr/lib/i486-linux-gnu? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch and idea for improved diversions and alternatives handling
On Fri, 2008-07-04 at 08:33 +0200, Tollef Fog Heen wrote: * Neil Williams | Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all | when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire | package under that, as we do with dpkg-cross currently: How would you then handle libraries that go in /lib? (Apart from the fact that I think just using a subdirectory of /usr/lib is much neater than random subdirectories in /usr. /lib/ /arm-linux-gnu/lib/ (did I miss that bit?) A single subdirectory of /usr is, IMHO, neater than a subdirectory of /usr/include and /usr/lib/. It would also mean less changes for those who are currently using multiple architectures on one system for the purposes of cross building. I wouldn't want to go the whole hog though and have /arm-linux-gnu/usr/lib /arm-linux-gnu/lib because that would be ugly, at least to me. | /usr/include/ | /usr/arm-linux-gnu/include/ Please note that the initial goal of multiarch at least has been just running of packages from foreign architectures. Not building them. True but the current usage of these mechanisms is in cross-building so sometimes the results of having to do something without major changes elsewhere can be helpful in designing the subsequent mechanism. | multiarch could even add: | /usr/share/ | /usr/arm-linux-gnu/share Pardon my language, but this is crack. The point of /usr/share is you can share it between systems. If you go down this route, just use a chroot and some wrapper scripts to bounce between them instead. It was only a suggestion for /usr/share - it was an alternative to renaming the package to get a different directory in /usr/share/ as the current tools do. Until all suitable packages have things like translations separated out into TDebs and other things like images in a -data or -common package instead of being packaged along with the architecture-dependent binaries, conflicts will occur if /usr/share is used as intended. Personally, I think it is better to avoid the need for complicated changes to diversions, alternatives or Replaces: if a simpler change in the packaging can achieve a smoother effect overall - albeit that the change in packaging would affect a lot more packages. Multiarch isn't needed for every possible package - not even every lib package or every binary package, changes can be made in the relevant package when people find a need to use that package as a multiarch package. [...] | BTW I think it is a mistake to want to use /usr/lib/i386/ when it is | entirely possible that multiarch users will actually need the full | triplet - think about hurd or kfreebsd as multiarch packages. I don't believe anybody has suggested using just /usr/lib/i386, but rather /usr/lib/i486-linux-gnu? OK - as I said, my connection has been flaky and I might have missed that bit. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Multiarch and idea for improved diversions and alternatives handling
On Tue, 2008-07-01 at 18:44 +0200, Goswin von Brederlow wrote: James Vega [EMAIL PROTECTED] writes: On Sat, Jun 28, 2008 at 02:03:05AM -0700, Steve Langasek wrote: So if we allow multiple packages to be installed at the same time which divert the same file, then I think we have another case for wanting to continue supporting an optional diversion target - or at least for not using .diverted by default, since we wouldn't want diversions from multiple packages to collide. Maybe .diverted-$package, then? (My internet connection has been very flaky since this thread started and I have only been able to post intermittently so apologies if this appears to be late or out-of-sync with other posts.) Just a thought - why use /usr/lib/$ARCH and /usr/include/$ARCH at all when it would (IMHO) be simpler to use /usr/$TRIPLET/ and put the entire package under that, as we do with dpkg-cross currently: /usr/lib/ /usr/arm-linux-gnu/lib/ /usr/include/ /usr/arm-linux-gnu/include/ multiarch could even add: /usr/share/ /usr/arm-linux-gnu/share This adds only one new directory, it keeps the main contents of the package in a single location (making it easier to manage and parse things like dpkg -L) and it means less changes for existing packages that use these paths already. It also means no need for extra diversions at all, no need for Replaces: and no headaches when removing the multiarch vs removing the primary package etc. BTW I think it is a mistake to want to use /usr/lib/i386/ when it is entirely possible that multiarch users will actually need the full triplet - think about hurd or kfreebsd as multiarch packages. There are two use cases to consider regarding multiple packages and diversions. 1) Multiple packages installing a file that has been diverted. Currently, there is only one divert to filename so you'll end up losing data once the second diverted file is installed. This could be alleviated by instead basing the divert to filename on the package which contains the file being diverted (as you suggest above). There's still the problem of what to do when the package providing the diversion is uninstalled as now you have conflicting packages. Actually, you already had conflicting packages that just weren't affected yet because of the diversion, which leads to 2). If the multiarch package can be installed alongside the primary without any conflicts by using /usr/$triplet instead, then the need for the diversion and consequent hacks goes away entirely. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
