FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian dpkg

 
 
LinkBack Thread Tools
 
Old 07-04-2008, 06:33 AM
Tollef Fog Heen
 
Default 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 debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-04-2008, 06:33 AM
Tollef Fog Heen
 
Default 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 06:54 AM
Tollef Fog Heen
 
Default 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 debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-07-2008, 06:54 AM
Tollef Fog Heen
 
Default 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-08-2008, 05:26 AM
Goswin von Brederlow
 
Default Multiarch and idea for improved diversions and alternatives handling

Neil Williams <codehelp@debian.org> writes:

> On Tue, 2008-07-01 at 18:44 +0200, Goswin von Brederlow wrote:
>> James Vega <jamessan@debian.org> 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 debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-08-2008, 05:26 AM
Goswin von Brederlow
 
Default Multiarch and idea for improved diversions and alternatives handling

Neil Williams <codehelp@debian.org> writes:

> On Tue, 2008-07-01 at 18:44 +0200, Goswin von Brederlow wrote:
>> James Vega <jamessan@debian.org> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-10-2008, 09:20 AM
Goswin von Brederlow
 
Default Multiarch and idea for improved diversions and alternatives handling

Neil Williams <codehelp@debian.org> 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 debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-10-2008, 09:20 AM
Goswin von Brederlow
 
Default Multiarch and idea for improved diversions and alternatives handling

Neil Williams <codehelp@debian.org> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:07 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org