Re: Updating dpkg-cross: file moving question
The question is - how to process existing cross-compile environment, created by earlier versions of dpkg-cross. I am thinking to make the following trick. In postinst of new dpkg-cross, it will check for /usr/arm-linux, /usr/powerpc-linux/, and other places where packages created by earlier versions could place files. If any of such directories is found: - a directory with the new name will be created if not exists yet, - complete file hierarchy from the old directory will be copied to the new directory, - old directory will be replaces with a sympink to the new one. Looks that this procedure is more or less safe. E.g. removals of packages which files have been moved in this way, would remove correct files. I've thought of an alternative way. I may make dpkg-cross to generate additional provides/depends information for arch-cross packages: - each xxx-arch-cross package will Provides: xxx-arch-cross-layout-identifier - when xxx deepnds on yyy, dpkg-cross will generate Depends: yyy-arch-cross, yyy-arch-cross-layout-identifier - when xxx depends on yyy (= n), dpkg-cross will generate Depends: yyy-arch-cross (= n), yyy-arch-cross-layout-identifier Looks that this guarantees that cross-compile setup at new location will be consistent. Also, it will make all package installations and removals clean. Drawback are: - tree at old location may become inconsistent (if x depends on y, x-arch-cross is generated by new dpkg-cross, and y-arch-cross is generated by old dpkg-cross), - if older (sarge) cross-compiler packages are used, they won't find cross-compilation tree unless symlinks are created manually. Does this look better? pgpebAnb7KHH7.pgp Description: PGP signature
Re: Updating dpkg-cross: file moving question
- tree at old location may become inconsistent (if x depends on y, x-arch-cross is generated by new dpkg-cross, and y-arch-cross is generated by old dpkg-cross), I meant 'y depends on x'. pgpIcwjCKqUZO.pgp Description: PGP signature
Re: Updating dpkg-cross: file moving question
Nikita V. Youshchenko [EMAIL PROTECTED] writes:
Dpkg-cross is a tool to create cross-compile environment, useful to
cross-compile debian packages and other software.
One of dpkg-cross's functions is to process a native library or libdev
package for some arch, and turn it into arch-all packages that install
libraries info /usr/$DEB_TARGET_GNU_ARCH)/lib/, and headers
info /usr/$(DEB_TARGET_GNU_ARCH)/include/. E.g. arm cross-compile
environment was created under /usr/arm-linux/. This was consistent
with cross-binutils and cross-gcc packages file placement.
That isn't where the multiarch proposals for Debian and FHS place
files and I think it is best if you follow their lead. Use
/usr/lib/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/
/usr/include/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/
Hmm...
All cross toolchains I've seen up to today, both free and commercial, use
include/ and lib/ subdirectories of some prefix.
Cross-ld from binutils use ${prefix}/${target}/lib these are the path to
search libraries.
Cross-gcc also uses ${prefix}/${target}/include and
${prefix}/${target}/lib.
This is how things used to work for years.
There should be a very serious reason to change this.
The multiarch and FHS proposals say that ${prefix}/${target}/* would
pollute the / and /usr directories while the lib and include subdirs
already have tons of files/dirs and the extra dirs won't matter.
Matter of opinion probably.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updating dpkg-cross: file moving question
Goswin von Brederlow [EMAIL PROTECTED] writes:
The multiarch and FHS proposals say that ${prefix}/${target}/* would
pollute the / and /usr directories while the lib and include subdirs
already have tons of files/dirs and the extra dirs won't matter.
Matter of opinion probably.
Of course. It's unlikely to be very serious pollution though, as it
will almost always be only 1 or 2 extra dirs, not many -- and it _is_
long-standing practice, and has the additional benefit of encapsulating
arch-specific hierarchies.
[I've come to depend on the FHS always making the wrong choice though.]
-Miles
--
Run away! Run away!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updating dpkg-cross: file moving question
Nikita V. Youshchenko [EMAIL PROTECTED] writes:
Dpkg-cross is a tool to create cross-compile environment, useful to
cross-compile debian packages and other software.
One of dpkg-cross's functions is to process a native library or
libdev package for some arch, and turn it into arch-all packages
that install libraries info /usr/$DEB_TARGET_GNU_ARCH)/lib/, and
headers info /usr/$(DEB_TARGET_GNU_ARCH)/include/. E.g. arm
cross-compile environment was created under /usr/arm-linux/. This
was consistent with cross-binutils and cross-gcc packages file
placement.
That isn't where the multiarch proposals for Debian and FHS place
files and I think it is best if you follow their lead. Use
/usr/lib/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/
/usr/include/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/
Hmm...
All cross toolchains I've seen up to today, both free and commercial,
use include/ and lib/ subdirectories of some prefix.
Cross-ld from binutils use ${prefix}/${target}/lib these are the path
to search libraries.
Cross-gcc also uses ${prefix}/${target}/include and
${prefix}/${target}/lib.
This is how things used to work for years.
There should be a very serious reason to change this.
The multiarch and FHS proposals say that ${prefix}/${target}/* would
pollute the / and /usr directories while the lib and include subdirs
already have tons of files/dirs and the extra dirs won't matter.
I think that following years-old de-facto standard of cross-compilation
environment file placing outweights '/usr pollution' argument.
So I think I will keep this as is in dpkg-cross. However, this may change
if other arguments will appear in future.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updating dpkg-cross: file moving question
Nikita V. Youshchenko [EMAIL PROTECTED] writes:
The multiarch and FHS proposals say that ${prefix}/${target}/* would
pollute the / and /usr directories while the lib and include subdirs
already have tons of files/dirs and the extra dirs won't matter.
I think that following years-old de-facto standard of cross-compilation
environment file placing outweights '/usr pollution' argument.
So I think I will keep this as is in dpkg-cross. However, this may change
if other arguments will appear in future.
Please contact the FHS people about this. This is best fixed prior to
the FHS multiarch stuff getting used in say SuSe or RH.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updating dpkg-cross: file moving question
The multiarch and FHS proposals say that ${prefix}/${target}/* would
pollute the / and /usr directories while the lib and include subdirs
already have tons of files/dirs and the extra dirs won't matter.
I think that following years-old de-facto standard of
cross-compilation environment file placing outweights '/usr pollution'
argument.
So I think I will keep this as is in dpkg-cross. However, this may
change if other arguments will appear in future.
Please contact the FHS people about this. This is best fixed prior to
the FHS multiarch stuff getting used in say SuSe or RH.
Could you please give some links - whom to contact, what better to read
before, etc ?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updating dpkg-cross: file moving question
Nikita V. Youshchenko [EMAIL PROTECTED] writes:
The multiarch and FHS proposals say that ${prefix}/${target}/* would
pollute the / and /usr directories while the lib and include subdirs
already have tons of files/dirs and the extra dirs won't matter.
I think that following years-old de-facto standard of
cross-compilation environment file placing outweights '/usr pollution'
argument.
So I think I will keep this as is in dpkg-cross. However, this may
change if other arguments will appear in future.
Please contact the FHS people about this. This is best fixed prior to
the FHS multiarch stuff getting used in say SuSe or RH.
Could you please give some links - whom to contact, what better to read
before, etc ?
Try
Mithrandir [Tollef Fog Heen] on irc
and
http://www.linuxbase.org/futures/ideas/multiarch/
Matt Taggart [EMAIL PROTECTED]
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Updating dpkg-cross: file moving question
Hello. I'm going to update dpkg-cross package, to follow post-sarge changes in dpkg and company. Dpkg-cross is a tool to create cross-compile environment, useful to cross-compile debian packages and other software. One of dpkg-cross's functions is to process a native library or libdev package for some arch, and turn it into arch-all packages that install libraries info /usr/$DEB_TARGET_GNU_ARCH)/lib/, and headers info /usr/$(DEB_TARGET_GNU_ARCH)/include/. E.g. arm cross-compile environment was created under /usr/arm-linux/. This was consistent with cross-binutils and cross-gcc packages file placement. In newer dpkg tools, target names changed, e.g. arm-linux turned into arm-linux-gnu. So, to keep system consistent, dpkg-cross should now place things under /usr/arm-linux/gnu/. The question is - how to process existing cross-compile environment, created by earlier versions of dpkg-cross. I am thinking to make the following trick. In postinst of new dpkg-cross, it will check for /usr/arm-linux, /usr/powerpc-linux/, and other places where packages created by earlier versions could place files. If any of such directories is found: - a directory with the new name will be created if not exists yet, - complete file hierarchy from the old directory will be copied to the new directory, - old directory will be replaces with a sympink to the new one. Looks that this procedure is more or less safe. E.g. removals of packages which files have been moved in this way, would remove correct files. Is it OK to go this way? Maybe, something better could be suggested? This is still not perfect: for example, it is never safe to remove created symlinks; also cross-compile environment will become broken if -arch-cross packages created with old and new dpkg-cross are mixed and dpkg-cross itself is either old or not installed. However, isn't it better than doing nothing (in which case any mixing of -arch-cross packages created by old and new dpkg-cross will be broken)? Nikita pgpUt8KBDwqFY.pgp Description: PGP signature
Re: Updating dpkg-cross: file moving question
Nikita V. Youshchenko [EMAIL PROTECTED] writes: Hello. I'm going to update dpkg-cross package, to follow post-sarge changes in dpkg and company. Dpkg-cross is a tool to create cross-compile environment, useful to cross-compile debian packages and other software. One of dpkg-cross's functions is to process a native library or libdev package for some arch, and turn it into arch-all packages that install libraries info /usr/$DEB_TARGET_GNU_ARCH)/lib/, and headers info /usr/$(DEB_TARGET_GNU_ARCH)/include/. E.g. arm cross-compile environment was created under /usr/arm-linux/. This was consistent with cross-binutils and cross-gcc packages file placement. That isn't where the multiarch proposals for Debian and FHS place files and I think it is best if you follow their lead. Use /usr/lib/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/ /usr/include/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/ In newer dpkg tools, target names changed, e.g. arm-linux turned into arm-linux-gnu. So, to keep system consistent, dpkg-cross should now place things under /usr/arm-linux/gnu/. The question is - how to process existing cross-compile environment, created by earlier versions of dpkg-cross. I am thinking to make the following trick. In postinst of new dpkg-cross, it will check for /usr/arm-linux, /usr/powerpc-linux/, and other places where packages created by earlier versions could place files. If any of such directories is found: - a directory with the new name will be created if not exists yet, - complete file hierarchy from the old directory will be copied to the new directory, - old directory will be replaces with a sympink to the new one. Looks that this procedure is more or less safe. E.g. removals of packages which files have been moved in this way, would remove correct files. The target directory would not be removed. Is it OK to go this way? Maybe, something better could be suggested? This is still not perfect: for example, it is never safe to remove created symlinks; also cross-compile environment will become broken if -arch-cross packages created with old and new dpkg-cross are mixed and dpkg-cross itself is either old or not installed. However, isn't it better than doing nothing (in which case any mixing of -arch-cross packages created by old and new dpkg-cross will be broken)? Nikita MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updating dpkg-cross: file moving question
Dpkg-cross is a tool to create cross-compile environment, useful to
cross-compile debian packages and other software.
One of dpkg-cross's functions is to process a native library or libdev
package for some arch, and turn it into arch-all packages that install
libraries info /usr/$DEB_TARGET_GNU_ARCH)/lib/, and headers
info /usr/$(DEB_TARGET_GNU_ARCH)/include/. E.g. arm cross-compile
environment was created under /usr/arm-linux/. This was consistent
with cross-binutils and cross-gcc packages file placement.
That isn't where the multiarch proposals for Debian and FHS place
files and I think it is best if you follow their lead. Use
/usr/lib/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/
/usr/include/$(DEB_HOST_GNU_CPU)-$(DEB_HOST_ARCH_OS)/
Hmm...
All cross toolchains I've seen up to today, both free and commercial, use
include/ and lib/ subdirectories of some prefix.
Cross-ld from binutils use ${prefix}/${target}/lib these are the path to
search libraries.
Cross-gcc also uses ${prefix}/${target}/include and
${prefix}/${target}/lib.
This is how things used to work for years.
There should be a very serious reason to change this.
In newer dpkg tools, target names changed, e.g. arm-linux turned into
arm-linux-gnu. So, to keep system consistent, dpkg-cross should now
place things under /usr/arm-linux/gnu/.
The question is - how to process existing cross-compile environment,
created by earlier versions of dpkg-cross.
I am thinking to make the following trick. In postinst of new
dpkg-cross, it will check for /usr/arm-linux, /usr/powerpc-linux/, and
other places where packages created by earlier versions could place
files. If any of such directories is found:
- a directory with the new name will be created if not exists yet,
- complete file hierarchy from the old directory will be copied to the
new directory,
- old directory will be replaces with a sympink to the new one.
Looks that this procedure is more or less safe. E.g. removals of
packages which files have been moved in this way, would remove correct
files.
The target directory would not be removed.
Yes, I see.
This is one more drawback.
In future dpkg-cross versions, I'll probably make -arch-cross packages to
provide 'dpkg-cross-layout-arch-version', and conflict with older
versions, so inconsistent setup could be more or less easilly avoided if
layout will ever change in future. Or something similar.
But currently, seems there is no way to avoid inconsistency cleanly, so
question is - try some tricks to avoid it in 'standard cases', by the cost
of mentioned drawbacks, or just add a news entry asking users to
regenerate all -arch-cross packages with new dpkg-cross, and leave the
rest to the users.
Nikita
pgprCjhgnfdxn.pgp
Description: PGP signature
