Bug#454057: please move dpkg-architecture
Raphael Hertzog a écrit : On Wed, 05 Dec 2007, Julien Cristau wrote: Or we can change type-handling too. Apparently xorg only uses the fact that type-handling provides not+sparc but it doesn't use the type-handling program which is the real user of dpkg-architecture. Is that right? Yes, that's correct. Maybe type-handling could be split with an empty package whose sole purpose is to Provides some virtual packages while type-handling stays the program with its dpkg-dev dependency. I think this solution would be my first preference. My preference would be for dpkg to allow 'Depends: foo [arch]' in arch:all packages, but failing that, I agree. Right now the support for the [arch] syntax is only in the perl code and not at all in the C part that concerns dpkg. Adding it there is a non-trivial effort and would probably also require changes in apt-based software. Aurélien, what do you think of the idea of change concerning type-handling ? From my point of view, we should get rid of type-handling as soon as possible. This is actually a big and buggy hack to workaround dpkg/apt lacks. The first think I would like to see, is [os] or [cpu] support in dpkg-dev *enabled* and *allowed* for arch-any packages. This would replace type-handling in 90% of the cases. For the [arch] support in binary-all packages, I guess the main use case (if not all) is for metapackages depending on various packages. I don't really see the problem (except the policy, but that can be changed) of using binary-any packages for those metapackages, even if there is no binary files insude them. They are by definition very small, so that won't bloat the archive. If there are still some cases not solved by this approach, I guess the package that should provide the not+sparc package is dpkg. It is always installed on systems, so strange behaviours of apt with virtual packages is avoided. That's why we have type-handling installed on GNU/kFreeBSD build daemons by default (GNU/kFreeBSD uses type-handling more than other architectures). -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453885: dpkg-shlibdeps changes can't track symlinks (/usr/lib, /usr/lib64)
On Mon, 03 Dec 2007, Matthias Klose wrote: Hum, /usr/lib64 is scanned after /usr/lib so it means that debian/gcj-4.3/usr/lib/gcc/x86_64-linux-gnu/4.3/ecj1 has a RPATH pointing to /usr/lib64 ... Is that true ? Is there a good reason for this ? maybe not; but this kind of thing is hardcoded upstream, so you'll see this in other packages as well. I know we're not going to clean all RPATH magically, but it might still be nice to clean them progressively. :) I'll still fix the generic problem that dpkg-shlibdeps has been seeing. Since the soname is different, it shouldn't create any problem. no, then all the -gcj packages would depend on libgcj8-1, not on libgcj-bc. That's not true. You can perfectly put a shlibs file in libgcj8-1 that's going to generate a dependency on libgcj-bc for binaries linked to libgcj_bc.so.1. Please consider this approach. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#453267: tested patch
On Tue, 04 Dec 2007, Neil Williams wrote:
On Wed, 5 Dec 2007 00:01:22 +0100
Raphael Hertzog [EMAIL PROTECTED] wrote:
On Tue, 04 Dec 2007, Neil Williams wrote:
+my @shlibdeps=();
+# ARCH for some awkward builds
+my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if
($ENV{ARCH});
What's the role of $ARCH ? And why shall we consider that we're
crossbuilding only because this variable is set ?
Not cross building - building a cross compiler.
Do we need to check twice for building a cross-compiler ? We don't need to
check $ARCH if we already have DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE,
no ?
gcc relies on $ARCH when preparing libgcc1-$arch-cross and other
toolchain libraries.
Fine, but I don't think that dpkg-shlibdeps has to check $ARCH at all.
Without the patch, I get:
dpkg-shlibdeps: failure: couldn't find library libc.so.6 needed by
debian/libgcc1-arm-cross/usr/arm-linux-gnu/lib/libgcc_s.so.1 (its RPATH
is '').
OK, but this means that you can't build a cross-compiler without having
the target libc6 ... which in theory you might not yet have since the
cross-compiler might be your only choice to compile that library.
Is that a real requirement or just a consequence of the fact that
dpkg-shlibdeps got more strict in the checks that it does ?
Maybe, the call to dpkg-shlibdeps should exclude files found below
/usr/$target/ ... this can be easily done with dh_shlibdeps.
+# host for normal cross builds.
+$crossprefix = $ENV{DEB_HOST_GNU_TYPE}
+if (($ENV{DEB_HOST_GNU_TYPE}) and ($ENV{DEB_HOST_GNU_TYPE} ne
$ENV{DEB_BUILD_GNU_TYPE}));
I think you should use the functions contained in Dpkg::Arch instead of
relying only the environment variables here...
Those variables are only defined in a cross build, not when building a
cross compiler or a toolchain.
Yes and what does that have to do with my remark ? Using the functions
instead of the variables is still nicer to detect a cross build.
My remark was generic and didn't concern the case of building a
cross-compiler at all.
Why would we need a special treatment of libs when creating a
cross-compiler? The cross-compiler runs on the build arch but is not linked
against any lib of the target arch so it doesn't need to scan the
directories of the target arch.
The cross compiler needs to build cross libraries that *are* called
when preparing the cross compiler itself.
Are called ? You mean that are analyzed by dpkg-shlibdeps ?
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Processed: Re: Processed: Re: Bug#454379: libzvbi0 -- Doesn't purge all files after piuparts Install+Upgrade+Purge test
Processing commands for [EMAIL PROTECTED]: retitle 454379 obsolete conffiles are not deleted on purge Bug#454379: libzvbi0 -- Doesn't purge all files after piuparts Install+Upgrade+Purge test Changed Bug title to `obsolete conffiles are not deleted on purge' from `libzvbi0 -- Doesn't purge all files after piuparts Install+Upgrade+Purge test'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454379: Processed: Re: Bug#454379: libzvbi0 -- Doesn't purge all files after piuparts Install+Upgrade+Purge test
retitle 454379 obsolete conffiles are not deleted on purge thanks Hi, On Wed, 05 Dec 2007, Debian Bug Tracking System wrote: reassign 454379 dpkg Bug#454379: libzvbi0 -- Doesn't purge all files after piuparts Install+Upgrade+Purge test Bug reassigned from package `libzvbi0' to `dpkg'. Christian, this has been hastily reassigned to dpkg. You should at least explain the problem... As far as I understand, the file /etc/default/libzvbi0 was in the sarge package but it's no more in the sid version of the package but the conf files stays even after the purge because: - dpkg doesn't remove conffiles on upgrade, it just mark them as obsolete (can be seen on dpkg -s package in the Conffiles field) - apparently even during purge it doesn't remove conffiles which are obsolete Can you confirm ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#454379: Processed: Re: Bug#454379: libzvbi0 -- Doesn't purge all files after piuparts Install+Upgrade+Purge test
Dear Raphael, Please CC me as well, as I am the submiter. On Wed, Dec 05, 2007 at 08:47:51PM +0100, Raphael Hertzog wrote: As far as I understand, the file /etc/default/libzvbi0 was in the sarge package but it's no more in the sid version of the package but the conf files stays even after the purge because: - dpkg doesn't remove conffiles on upgrade, it just mark them as obsolete (can be seen on dpkg -s package in the Conffiles field) - apparently even during purge it doesn't remove conffiles which are obsolete Can you confirm ? From my observation, if the conffile is present in the Etch package[1], but not in the Sid package[2], dpkg leaves the conffile during upgrade and forgets about them on subsequent purge. I think Christian feels that this is to be handled by dpkg. [1]: http://packages.debian.org/etch/i386/libzvbi0/filelist [2]: http://packages.debian.org/sid/i386/libzvbi0/filelist HTH. Thanks. Kumar -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Bug#454057: please move dpkg-architecture
Hi, On Wed, 2007-12-05 at 20:02:34 +0100, Aurelien Jarno wrote: Raphael Hertzog a écrit : On Wed, 05 Dec 2007, Julien Cristau wrote: Maybe type-handling could be split with an empty package whose sole purpose is to Provides some virtual packages while type-handling stays the program with its dpkg-dev dependency. I think this solution would be my first preference. I've been meaning to discuss this with the XSF but at some point forgot about it. I'd really like if you guys could switch that package to arch:any (reasons given below). My preference would be for dpkg to allow 'Depends: foo [arch]' in arch:all packages, but failing that, I agree. Right now the support for the [arch] syntax is only in the perl code and not at all in the C part that concerns dpkg. Adding it there is a non-trivial effort and would probably also require changes in apt-based software. The '[arch]' is supported in the perl code but the dependencies are reduced at package build time. The C code is not the problem with this solution (implementing this is not that difficult, although the arch wildcard support would have to be reimplemented in C), the main problem is breaking all programs around that might be parsing the dependency fields, like sbuild, pbuilder, apt-based, etc. Aurélien, what do you think of the idea of change concerning type-handling ? From my point of view, we should get rid of type-handling as soon as possible. This is actually a big and buggy hack to workaround dpkg/apt lacks. Agreed, and that was our main goal when we (although it has been Aurélien who has done all the work) took over that package. Part of the failure is probably on me for not having pushed enough for the arch wildcards... The first think I would like to see, is [os] or [cpu] support in dpkg-dev *enabled* and *allowed* for arch-any packages. This would replace type-handling in 90% of the cases. I suppose you mean the arch wildcards like '[os-any]' and '[any-cpu]', this has been supported since latest part of the etch release which is the most annoying part type-handling is working around and that's the reason it got added then, to be able to easily get rid of type-handling. The only reason we cannnot use it now is sbuild, I sent a mail to Ryan some time ago but he didn't reply. For the [arch] support in binary-all packages, I guess the main use case (if not all) is for metapackages depending on various packages. I don't really see the problem (except the policy, but that can be changed) of using binary-any packages for those metapackages, even if there is no binary files insude them. They are by definition very small, so that won't bloat the archive. I agree. There's probably really few cases where an arch:all needs to Depend on a package only present in a specific architecture. I'm not sure it's worth the effort, also ideally we should have less arch specific packages. If there are still some cases not solved by this approach, I guess the package that should provide the not+sparc package is dpkg. It is always installed on systems, so strange behaviours of apt with virtual packages is avoided. Right, but I'm a bit uneasy on this solution of abusing the dependencies for that purpose. I'll be closing this bug report and the one on type-handling about splitting the package in few days. regards, guillem
Bug#454379: Processed: Re: Bug#454379: libzvbi0 -- Doesn't purge all files after piuparts Install+Upgrade+Purge test
On Thu, Dec 06, 2007 at 07:28:03AM +0530, Kumar Appaiah wrote: On Wed, Dec 05, 2007 at 08:47:51PM +0100, Raphael Hertzog wrote: As far as I understand, the file /etc/default/libzvbi0 was in the sarge package but it's no more in the sid version of the package but the conf files stays even after the purge because: - dpkg doesn't remove conffiles on upgrade, it just mark them as obsolete (can be seen on dpkg -s package in the Conffiles field) - apparently even during purge it doesn't remove conffiles which are obsolete Can you confirm ? From my observation, if the conffile is present in the Etch package[1], but not in the Sid package[2], dpkg leaves the conffile during upgrade and forgets about them on subsequent purge. I think Christian feels that this is to be handled by dpkg. Yeah, that is a known limitation of dpkg. See also http://www.dpkg.org/dpkg/ConffileHandling Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
