Hi,

I cleaned up some more of the old multiarch patches and hit another
spot where a decision must be made:

----------------------------------------------------------------------
Unpacking libhello/i386 (from .../libhello/libhello_1.0_i386.deb) ...
dpkg: error processing /home/mrvn/src/libhello/libhello_1.0_i386.deb (--install):
trying to overwrite `/usr/share/doc/libhello/changelog.gz', which is also in package libhello/amd64
----------------------------------------------------------------------

Every package must have a changelog and copyright and many also have a
Readme and NEWS file. Those and any other files in doc will collide
for multiarch.

Dpkg could rename the files for the non native architecture by
prefixing them with the architecture, e.g.
/usr/share/doc/libhello/i386_changelog.gz
or
/usr/share/doc/libhello/i386/changelog.gz

This could be done for just the standard files. But I think that is to
minimalistic. Many packages also have some examples or other small
files. Many packages would have to split them out into a tiny
<package>-common deb causing Packages.gz and the packages database to
bloat.

So I think for Multi-Arch: abi packages the /usr/share/doc/<package>
in its entirety should be renamed and now there is a choice to make:

1) Change policy

We could change policy to dictate that Multi-Arch: abi packages must
use /usr/share/doc/<package>_<DEB_HOST_ARCH>/ instead of the normal
directory. This would require some small changes in dpkg-* scripts and
debhelper. debian/rules for packages might not have to change at all.

This would also affect lintian, linda and packages.d.o.

2) Rename the files during extraction

This would require changes to dpkgs tar module. It would mean adding a
whole new rename mechanism or misusing the diversion code and I fear
would be somewhat complicated in the code flow.



I would prefer option 1. Irespective of the choice apt-listchanges
hase also to be changed.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, 26 Jun 2008, Goswin von Brederlow wrote:
> So I think for Multi-Arch: abi packages the /usr/share/doc/<package>
> in its entirety should be renamed and now there is a choice to make:

I like none of your suggestions. I'd like to suggest to rely on the
work done by Tollef that lets dpkg skip some files in packages. The first
purpose was to strip doc and locale data in some embedded usage
but it could be improved with new rules that exclude such common
name spaces for package which are for another architecture
than the current one.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Raphael Hertzog <hertzog@debian.org> writes:

> On Thu, 26 Jun 2008, Goswin von Brederlow wrote:
>> So I think for Multi-Arch: abi packages the /usr/share/doc/<package>
>> in its entirety should be renamed and now there is a choice to make:
>
> I like none of your suggestions. I'd like to suggest to rely on the
> work done by Tollef that lets dpkg skip some files in packages. The first
> purpose was to strip doc and locale data in some embedded usage
> but it could be improved with new rules that exclude such common
> name spaces for package which are for another architecture
> than the current one.
>
> Cheers,

So when I install iceweasel 32bit on amd64 (for stupid plugins) I will
have no copyright, changelog nor license? I doubt that would be legal.
Even for libaries there is no garanty that the native flavour of a
library will be present when another architectures flavour is
installed.

If a user wants to skip them that is their problem but Debian shipping
a dpkg that skips them allways or by default would be problematic.


Can you give me an url for Tollefs work? Maybe that can be used to
rename by default.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, 2008-06-26 at 14:56 +0200, Goswin von Brederlow wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
>
> > On Thu, 26 Jun 2008, Goswin von Brederlow wrote:
> >> So I think for Multi-Arch: abi packages the /usr/share/doc/<package>
> >> in its entirety should be renamed and now there is a choice to make:
> >
> > I like none of your suggestions. I'd like to suggest to rely on the
> > work done by Tollef that lets dpkg skip some files in packages. The first
> > purpose was to strip doc and locale data in some embedded usage
> > but it could be improved with new rules that exclude such common
> > name spaces for package which are for another architecture
> > than the current one.
> >
> > Cheers,
>
> So when I install iceweasel 32bit on amd64 (for stupid plugins) I will
> have no copyright, changelog nor license? I doubt that would be legal.
> Even for libaries there is no garanty that the native flavour of a
> library will be present when another architectures flavour is
> installed.

Your use case is a touch unusual (from my perspective anyway) - current
behaviour (via dpkg-cross) is focused on only providing the binaries of
a particular package for purposes of linking during cross builds, in
which case dropping everything not related to linkage is the obvious
solution, hence dpkg filtering and dpkg-cross.

Similarly, many multiarch dpkg runs will take place in a temporary
chroot during a cross-build - there isn't a need for any copyright or
changelog files in that situation. (Currently, these -cross packages are
generated on-the-fly from the Debian mirrors for the requested
architecture, obtained using apt-cross).

Actually running foreign binaries involves a different set of problems
(and dependencies). iceweasel 32bit on amd64 isn't what I would think of
as the typical use of dpkg multiarch support. If we are to continue
migrating dpkg-cross into dpkg, the multiarch support will need to
support installing ARM packages on amd64 and i386 - not for the purposes
of running them via qemu or anything else, purely for the purposes of
linking against them during builds.

> If a user wants to skip them that is their problem but Debian shipping
> a dpkg that skips them allways or by default would be problematic.

(Although common in a variety of embedded installations so by no means a
deal-breaker.)

Besides, dpkg-cross has been in Debian for a decade with the default
action doing precisely this kind of stripping:

$ dpkg -L libqof1-arm-cross
/.
/usr
/usr/arm-linux-gnu
/usr/arm-linux-gnu/lib
/usr/arm-linux-gnu/lib/libqof.so.1.0.10
/usr/share
/usr/share/doc
/usr/share/doc/libqof1-arm-cross
/usr/share/doc/libqof1-arm-cross/README
/usr/arm-linux-gnu/lib/libqof.so.1


> Can you give me an url for Tollefs work? Maybe that can be used to
> rename by default.

See this thread in the dpkg list archives:

http://lists.debian.org/debian-dpkg/2008/01/msg00001.html

And some other links for background:
http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/25-dpkg-filtering.html
http://www.emdebian.org/docs/howto-4.html


--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

On Thu, 2008-06-26 at 14:56 +0200, Goswin von Brederlow wrote:
> Can you give me an url for Tollefs work? Maybe that can be used to
> rename by default.

See this thread in the dpkg list archives:

Try this one instead:
http://lists.debian.org/debian-dpkg/2008/01/msg00011.html


--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Goswin von Brederlow wrote:

> Raphael Hertzog <hertzog@debian.org> writes:
>
>> On Thu, 26 Jun 2008, Goswin von Brederlow wrote:
>>> So I think for Multi-Arch: abi packages the /usr/share/doc/<package>
>>> in its entirety should be renamed and now there is a choice to make:
>>
>> I like none of your suggestions. I'd like to suggest to rely on the
>> work done by Tollef that lets dpkg skip some files in packages. The first
>> purpose was to strip doc and locale data in some embedded usage
>> but it could be improved with new rules that exclude such common
>> name spaces for package which are for another architecture
>> than the current one.
>>
>> Cheers,
>
> So when I install iceweasel 32bit on amd64 (for stupid plugins) I will
> have no copyright, changelog nor license? I doubt that would be legal.
> Even for libaries there is no garanty that the native flavour of a
> library will be present when another architectures flavour is
> installed.
>
> If a user wants to skip them that is their problem but Debian shipping
> a dpkg that skips them allways or by default would be problematic.

Maybe install the first one and skip the next? ie, if I install iceweasel 32
bits first, then /u/s/d/iceweasel gets installed. When I install the amd64
version, /u/s/d/iceweasel gets skipped.

Another option would be for dpkg to automatically assume that each arch
Replaces: the same package for other archs, and so it will just overwrite said
files.

--

Felipe Sateler


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, 2008-06-26 at 10:45 -0400, Felipe Sateler wrote:
> Goswin von Brederlow wrote:
>
> > Raphael Hertzog <hertzog@debian.org> writes:
> >
> >> On Thu, 26 Jun 2008, Goswin von Brederlow wrote:
> >>> So I think for Multi-Arch: abi packages the /usr/share/doc/<package>
> >>> in its entirety should be renamed and now there is a choice to make:
> >>
> >> I like none of your suggestions. I'd like to suggest to rely on the
> >> work done by Tollef that lets dpkg skip some files in packages. The first
> >> purpose was to strip doc and locale data in some embedded usage
> >> but it could be improved with new rules that exclude such common
> >> name spaces for package which are for another architecture
> >> than the current one.
> >>
> >> Cheers,
> >
> > So when I install iceweasel 32bit on amd64 (for stupid plugins) I will
> > have no copyright, changelog nor license? I doubt that would be legal.
> > Even for libaries there is no garanty that the native flavour of a
> > library will be present when another architectures flavour is
> > installed.
> >
> > If a user wants to skip them that is their problem but Debian shipping
> > a dpkg that skips them allways or by default would be problematic.
>
> Maybe install the first one and skip the next? ie, if I install iceweasel 32
> bits first, then /u/s/d/iceweasel gets installed. When I install the amd64
> version, /u/s/d/iceweasel gets skipped.
>
> Another option would be for dpkg to automatically assume that each arch
> Replaces: the same package for other archs, and so it will just overwrite said
> files.

If we are to have automated Replaces:, wouldn't it make sense to assert
that the "primary arch" replaces all other architectures?

i.e. in the same manner as the buildd allows Architecture: all uploads
for the first upload but requires -B builds for the ports.

Whichever is the primary system architecture (according to
dpkg-architecture when passed no arguments) has first call on all files
installed for that architecture - everything else is deemed to be
replaced by the primary. In the case of conflict or Replaces: the files
stay under the ownership of the primary architecture.

The problem with arbitrary or sequential decisions on Replaces: is that
whichever package finally gets the "flag" ends up with ownership so if
the user removes the multiarch but leaves the primary, the files are not
put back because Replaces: is already in effect.

If users install a multiarch version without the primary version, is
that something dpkg even needs to worry about? The default (to me)
should be to preserve the primary architecture and ensure that if the
multiarch package is purged, the primary architecture package is still
in a pristine state. Allowing the multiarch to Replace: the primary will
only ensure that the primary arch package is always incomplete if the
multiarch is ever removed.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Neil Williams <codehelp@debian.org> writes:

> On Thu, 2008-06-26 at 14:56 +0200, Goswin von Brederlow wrote:
>> Raphael Hertzog <hertzog@debian.org> writes:
>>
>> > On Thu, 26 Jun 2008, Goswin von Brederlow wrote:
>> >> So I think for Multi-Arch: abi packages the /usr/share/doc/<package>
>> >> in its entirety should be renamed and now there is a choice to make:
>> >
>> > I like none of your suggestions. I'd like to suggest to rely on the
>> > work done by Tollef that lets dpkg skip some files in packages. The first
>> > purpose was to strip doc and locale data in some embedded usage
>> > but it could be improved with new rules that exclude such common
>> > name spaces for package which are for another architecture
>> > than the current one.
>> >
>> > Cheers,
>>
>> So when I install iceweasel 32bit on amd64 (for stupid plugins) I will
>> have no copyright, changelog nor license? I doubt that would be legal.
>> Even for libaries there is no garanty that the native flavour of a
>> library will be present when another architectures flavour is
>> installed.
>...
> Actually running foreign binaries involves a different set of problems
> (and dependencies). iceweasel 32bit on amd64 isn't what I would think of
> as the typical use of dpkg multiarch support. If we are to continue
> migrating dpkg-cross into dpkg, the multiarch support will need to
> support installing ARM packages on amd64 and i386 - not for the purposes
> of running them via qemu or anything else, purely for the purposes of
> linking against them during builds.

The whole point of multiarch (as opposed to dpkg-cross) is to be able
to run binaries without a clumsy chroot. Running wine, arobat reader,
iceweasel with 32bit plugins, mplayer with win32 codecs, google earth,
skype, ... is a verry real use case. From that side the ability to
cross-compile is purely a bonus.

For me having cross-compiling supported by multiarch is a nice bonus
but not my motivation. But done right we do get it for free which is
verry cool.

>> If a user wants to skip them that is their problem but Debian shipping
>> a dpkg that skips them allways or by default would be problematic.
>
> (Although common in a variety of embedded installations so by no means a
> deal-breaker.)
>
> Besides, dpkg-cross has been in Debian for a decade with the default
> action doing precisely this kind of stripping:
>
> $ dpkg -L libqof1-arm-cross
> /.
> /usr
> /usr/arm-linux-gnu
> /usr/arm-linux-gnu/lib
> /usr/arm-linux-gnu/lib/libqof.so.1.0.10
> /usr/share
> /usr/share/doc
> /usr/share/doc/libqof1-arm-cross
> /usr/share/doc/libqof1-arm-cross/README
> /usr/arm-linux-gnu/lib/libqof.so.1

Doesn't make it legal though.

>> Can you give me an url for Tollefs work? Maybe that can be used to
>> rename by default.
>
> See this thread in the dpkg list archives:
>
> http://lists.debian.org/debian-dpkg/2008/01/msg00001.html
>
> And some other links for background:
> http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/25-dpkg-filtering.html
> http://www.emdebian.org/docs/howto-4.html

Thanks.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Felipe Sateler <fsateler@gmail.com> writes:

> Goswin von Brederlow wrote:
>
>> Raphael Hertzog <hertzog@debian.org> writes:
>>
>>> On Thu, 26 Jun 2008, Goswin von Brederlow wrote:
>>>> So I think for Multi-Arch: abi packages the /usr/share/doc/<package>
>>>> in its entirety should be renamed and now there is a choice to make:
>>>
>>> I like none of your suggestions. I'd like to suggest to rely on the
>>> work done by Tollef that lets dpkg skip some files in packages. The first
>>> purpose was to strip doc and locale data in some embedded usage
>>> but it could be improved with new rules that exclude such common
>>> name spaces for package which are for another architecture
>>> than the current one.
>>>
>>> Cheers,
>>
>> So when I install iceweasel 32bit on amd64 (for stupid plugins) I will
>> have no copyright, changelog nor license? I doubt that would be legal.
>> Even for libaries there is no garanty that the native flavour of a
>> library will be present when another architectures flavour is
>> installed.
>>
>> If a user wants to skip them that is their problem but Debian shipping
>> a dpkg that skips them allways or by default would be problematic.
>
> Maybe install the first one and skip the next? ie, if I install iceweasel 32
> bits first, then /u/s/d/iceweasel gets installed. When I install the amd64
> version, /u/s/d/iceweasel gets skipped.

And if the first one then gets removed? In dpkg a file belongs to
exactly one package and one package only with the exception of
diversions which add a second package and a second package only.

> Another option would be for dpkg to automatically assume that each arch
> Replaces: the same package for other archs, and so it will just overwrite said
> files.

I'm not sure multiple replaces against each other will work out well
in dpkg. Probably would result in total chaos of file ownership over
time. When some library gets removed random files would disapear while
others remain. Don't like such randomness.

Also other files would replace themself too which is certainly not
wanted. I want to know if a library package ships /usr/bin/foo-helper,
which is a policy violation by the way.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Thu, Jun 26, 2008 at 01:32:47AM +0200, Goswin von Brederlow wrote:
> Hi,
>
> I cleaned up some more of the old multiarch patches and hit another
> spot where a decision must be made:
>
> ----------------------------------------------------------------------
> Unpacking libhello/i386 (from .../libhello/libhello_1.0_i386.deb) ...
> dpkg: error processing /home/mrvn/src/libhello/libhello_1.0_i386.deb (--install):
> trying to overwrite `/usr/share/doc/libhello/changelog.gz', which is also in package libhello/amd64
> ----------------------------------------------------------------------
>
> Every package must have a changelog and copyright and many also have a
> Readme and NEWS file. Those and any other files in doc will collide
> for multiarch.
>
> Dpkg could rename the files for the non native architecture by
> prefixing them with the architecture, e.g.
> /usr/share/doc/libhello/i386_changelog.gz
> or
> /usr/share/doc/libhello/i386/changelog.gz

I don't really like this idea, this will most probably confuse the user,
while also probably duplicating data.

At some point it has been decided to provide a -common package for every
package converted to multiarch, containing changelog, README, NEWS, and
probably more thinks like man pages, info pages, etc.

Then multiarch package could simply add a link from
/usr/share/doc/package to /usr/share/doc/package-common, and we should
change dpkg to allow a symlink to be overrided by another if both point
to the same location.

What do you think?

--
.'`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org