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

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/

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

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/

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/

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/