Re: Help identify packages that multiarch support will break
Raphael Hertzog hert...@debian.org writes: [ Bcc to -dpkg for info ] Hello, since multiarch support in dpkg is on good track, it's about time to identify what will break when people start using multiarch packages... A while back I already posted about a major problem cases. Specifically packages violating Debian policy: 8.2 Shared library support files. That includes conffiles in /etc and binaries in /usr/bin. Both are already a problem if the library SONAME changes but will bite multiarch too. A rough check over all packages in unstable back then resulted in 126 library packages with conffiles and a further 926 (excluding those with conffiles) library packages with binaries. A library package being one with a shlibs file. What is the policy on conffiles under multiarch? Can a Multi-Arch: same package have conffiles? Or would that confuse dpkg too much? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqpi9krl.fsf@frosties.localnet
Re: Help identify packages that multiarch support will break
Hi, On Wed, 23 Mar 2011, Goswin von Brederlow wrote: What is the policy on conffiles under multiarch? Can a Multi-Arch: same package have conffiles? Or would that confuse dpkg too much? They can have conffiles but obviously the confffile must be the same across all architectures (for a given version). Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110323105746.ga20...@rivendell.home.ouaza.com
Re: Help identify packages that multiarch support will break
Raphael Hertzog hert...@debian.org writes: Hi, On Wed, 23 Mar 2011, Goswin von Brederlow wrote: What is the policy on conffiles under multiarch? Can a Multi-Arch: same package have conffiles? Or would that confuse dpkg too much? They can have conffiles but obviously the confffile must be the same across all architectures (for a given version). Cheers, And if I change the conffile and upgrade does dpkg then ask twice if I want to keep my version? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aagm9hmq.fsf@frosties.localnet
Re: Help identify packages that multiarch support will break
On Wed, 23 Mar 2011, Goswin von Brederlow wrote: They can have conffiles but obviously the confffile must be the same across all architectures (for a given version). And if I change the conffile and upgrade does dpkg then ask twice if I want to keep my version? No. What about stopping to ask silly questions and try it for yourself if you really want to find problems? git clone git://git.debian.org/users/hertzog/dpkg.git -b pu/multiarch/full Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110323124007.ga15...@rivendell.home.ouaza.com
Re: Help identify packages that multiarch support will break
* Raphael Hertzog [2011-03-02 15:06 +0100]: In general parsing the status file should not be done, instead you should use dpkg-query. Is there any reason for this, except that the format of the status files will evolve? You should use dpkg-query --control-path package something to Jftr, there is a lot potential for performance improvements in dpkg-query, some queries can be done way faster even in gawk. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110303130456.ga29...@furrball.stateful.de
Re: Help identify packages that multiarch support will break
Hi, On Thu, 03 Mar 2011, Carsten Hey wrote: * Raphael Hertzog [2011-03-02 15:06 +0100]: In general parsing the status file should not be done, instead you should use dpkg-query. Is there any reason for this, except that the format of the status files will evolve? dpkg-query will automatically respect DPKG_ADMINDIR if it's set (and it's set in maintainer scripts). (this is a new feature in the upcoming version) And the status file is not a public interface. It's a file used by dpkg. If tomorrow dpkg supports an optional SQLite internal database through a plugin, dpkg-query will continue to work but your access to the status file will not. (This is unlikely to happen any time soon, but you get the idea) You should use dpkg-query --control-path package something to Jftr, there is a lot potential for performance improvements in dpkg-query, some queries can be done way faster even in gawk. JFTR, there are also 300+ bugs in the BTS and we are two active developers on dpkg. dpkg-query is rarely used in performance sensitive situation, it's not really my priority to improve it. But if you want to help, you're welcome. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110303134551.gd11...@rivendell.home.ouaza.com
Re: Help identify packages that multiarch support will break
Hi! On Thu, 2011-03-03 at 14:45:51 +0100, Raphael Hertzog wrote: On Thu, 03 Mar 2011, Carsten Hey wrote: * Raphael Hertzog [2011-03-02 15:06 +0100]: In general parsing the status file should not be done, instead you should use dpkg-query. Is there any reason for this, except that the format of the status files will evolve? dpkg-query will automatically respect DPKG_ADMINDIR if it's set (and it's set in maintainer scripts). (this is a new feature in the upcoming version) And the status file is not a public interface. It's a file used by dpkg. If tomorrow dpkg supports an optional SQLite internal database through a plugin, dpkg-query will continue to work but your access to the status file will not. (This is unlikely to happen any time soon, but you get the idea) Well, the most important reason is that directly parsing the status file does not take into account the journal files. So yes, nothing should really be accessing anything under /var/lib/dpkg, although package manager frontends can be considered currently grandfathered as there's no sane interface provided by dpkg yet (read libdpkg) for their use, and they correctly handle the journal files anyway. You should use dpkg-query --control-path package something to Jftr, there is a lot potential for performance improvements in dpkg-query, some queries can be done way faster even in gawk. JFTR, there are also 300+ bugs in the BTS and we are two active developers on dpkg. dpkg-query is rarely used in performance sensitive situation, it's not really my priority to improve it. But if you want to help, you're welcome. That's on my TODO list. regards, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110303160243.ga1...@gaara.hadrons.org
Re: Help identify packages that multiarch support will break
Hi! On Wed, 2011-03-02 at 15:06:11 +0100, Raphael Hertzog wrote: Here's what might create troubles: 3/ Any program that assumes the current layout of control files (/var/lib/dpkg/info/package.something) will be broken (at least for some packages) since the layout will change to support Multi-Arch: same packages that can be co-installed. You should use dpkg-query --control-path package something to retrieve the path of the file. This has been introduced in dpkg 1.15.4 and is thus in squeeze already. An additional clarificaton, --control-path will not show internal information control files (currently .list and .conffiles), for those dpkg-query --listfiles or --status should be used instead, anything else should be considered broken. thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110303160836.gb1...@gaara.hadrons.org
Re: Help identify packages that multiarch support will break
On Thu, Mar 03, 2011 at 02:45:51PM +0100, Raphael Hertzog wrote:
And the status file is not a public interface. It's a file used by dpkg.
If tomorrow dpkg supports an optional SQLite internal database through a
plugin, dpkg-query will continue to work but your access to the status
file will not. (This is unlikely to happen any time soon, but you get the
idea)
Is there a way to ask dpkg-query to dump all the information contained
in /var/lib/dpkg/status without either having to: (1) list all fields
explicitly (using --show + --showformat) or (2) list all package names
(using --status)?
I co-maintain some utilities that parse /var/lib/dpkg/status and I'd be
glad to migrate them to dpkg-query, but both solutions above have
drawbacks. (1) is not future proof and will miss the addition of new
fields unless the utility is updated; (2) has a race condition in asking
the currently installed packages and providing them to --status (beside
being a horrible hack in requiring to list all package names as
arguments). Am I missing something?
Having the ability to pass a package (wildcard) pattern to --show would
be enough to solve this problem.
Do you want a bug report about this?
Thanks to the mighty dpkg maintainers!
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Help identify packages that multiarch support will break
On Thu, 2011-03-03 at 17:30:42 +0100, Stefano Zacchiroli wrote: On Thu, Mar 03, 2011 at 02:45:51PM +0100, Raphael Hertzog wrote: And the status file is not a public interface. It's a file used by dpkg. If tomorrow dpkg supports an optional SQLite internal database through a plugin, dpkg-query will continue to work but your access to the status file will not. (This is unlikely to happen any time soon, but you get the idea) Is there a way to ask dpkg-query to dump all the information contained in /var/lib/dpkg/status without either having to: (1) list all fields explicitly (using --show + --showformat) For each package --status will do the trick, for all packages, yeah it does not support patterns. I guess adding that would be fine. So one could do something like: «dpkg-query -s '*'». or (2) list all package names (using --status)? Currently something like «dpkg-query -l|tr -s ' ' '\t'|cut -f2» could do the trick, altough I could agree it sucks a bit. If --status would accept patterns that would be nicer. Having the ability to pass a package (wildcard) pattern to --show would be enough to solve this problem. Do you want a bug report about this? Yes, please. thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110303172001.ga2...@gaara.hadrons.org
Re: Help identify packages that multiarch support will break
Hi, On Thu, 03 Mar 2011, Stefano Zacchiroli wrote: Is there a way to ask dpkg-query to dump all the information contained in /var/lib/dpkg/status without either having to: (1) list all fields explicitly (using --show + --showformat) or (2) list all package names (using --status)? I co-maintain some utilities that parse /var/lib/dpkg/status and I'd be glad to migrate them to dpkg-query, but both solutions above have drawbacks. (1) is not future proof and will miss the addition of new fields unless the utility is updated; (2) has a race condition in asking the currently installed packages and providing them to --status (beside being a horrible hack in requiring to list all package names as arguments). Am I missing something? Having the ability to pass a package (wildcard) pattern to --show would be enough to solve this problem. If you don't pass any argument to --show you have all the installed packages. And wildcards are already supported in --show (but not in --status). We can add support for wildcards in --status, in fact it will be easily doable. Do you want to file a wishlist bug for this ? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110303172306.ga13...@rivendell.home.ouaza.com
Re: Help identify packages that multiarch support will break
On Thu, 2011-03-03 at 18:20:01 +0100, Guillem Jover wrote:
On Thu, 2011-03-03 at 17:30:42 +0100, Stefano Zacchiroli wrote:
Is there a way to ask dpkg-query to dump all the information contained
in /var/lib/dpkg/status without either having to: (1) list all fields
explicitly (using --show + --showformat)
For each package --status will do the trick, for all packages, yeah
it does not support patterns. I guess adding that would be fine. So
one could do something like: «dpkg-query -s '*'».
Or on a second though, just supporting «dpkg-query -s» would solve
your problem too, as you don't seem to actually need pattern support,
if there's a need for that we can always add them, obviously.
or (2) list all package names (using --status)?
Currently something like «dpkg-query -l|tr -s ' ' '\t'|cut -f2» could
do the trick, altough I could agree it sucks a bit. If --status would
accept patterns that would be nicer.
Huh, disregard this, as pointed out by Raphaël, which I had forgotten
somehow, just doing «dpkg-query -f '${Package}\n' -W» would work. In
my defense (if that's possible :), I've now fixed the documentation:
http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=7a86e423
thanks,
guillem
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110303180514.ga2...@gaara.hadrons.org
Re: Help identify packages that multiarch support will break
[ Cc-ing the bug log ]
On Thu, Mar 03, 2011 at 07:05:14PM +0100, Guillem Jover wrote:
For each package --status will do the trick, for all packages, yeah
it does not support patterns. I guess adding that would be fine. So
one could do something like: «dpkg-query -s '*'».
Or on a second though, just supporting «dpkg-query -s» would solve
your problem too, as you don't seem to actually need pattern support,
if there's a need for that we can always add them, obviously.
Yes, absolutely: for my dump needs, that would be enough. I'm not sure
there are other use cases who might benefit by globbing there though.
Currently something like «dpkg-query -l|tr -s ' ' '\t'|cut -f2» could
do the trick, altough I could agree it sucks a bit. If --status would
accept patterns that would be nicer.
Huh, disregard this, as pointed out by Raphaël, which I had forgotten
somehow, just doing «dpkg-query -f '${Package}\n' -W» would work. In
my defense (if that's possible :), I've now fixed the documentation:
http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=7a86e423
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
