[arch-dev-public] [signoff] xz-utils and libarchive-2.7.0-2
Hi devs, we had a long discussion about xz/lzma support some time ago. So I finally added xz-utils to testing and rebuild libarchive to make use of it. If everything is OK we can move both to core and remove lzma-utils from extra. I don't know if anything else has to be recompiled to add support for xz/lzma. PS: you can build xz archive with bsdtar (part of libarchive). PPS: the git version of pacman/makepkg (future 3.3) should support the xz format (not tested) -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Am Sonntag 31 Mai 2009 schrieb Pierre Schmitz:
Hi devs,
we had a long discussion about xz/lzma support some time ago. So I finally added xz-utils to testing and rebuild libarchive to make use of it.
If everything is OK we can move both to core and remove lzma-utils from extra.
I don't know if anything else has to be recompiled to add support for xz/lzma.
PS: you can build xz archive with bsdtar (part of libarchive). PPS: the git version of pacman/makepkg (future 3.3) should support the xz format (not tested) signoff for both arches, fsarchiver compiled fine greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am Sonntag 31 Mai 2009 14:14:48 schrieb Pierre Schmitz:
If everything is OK we can move both to core and remove lzma-utils from extra.
tpowa just asked me but I am not sure about it: Should cz-utils be part of the base group? It'll be installed anyway because libarchive depends on it. O the other hand we might want to have a base group which does not depend on anything which is not a group member. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Pierre Schmitz wrote:
Am Sonntag 31 Mai 2009 14:14:48 schrieb Pierre Schmitz:
If everything is OK we can move both to core and remove lzma-utils from extra.
tpowa just asked me but I am not sure about it: Should cz-utils be part of the base group? It'll be installed anyway because libarchive depends on it. O the other hand we might want to have a base group which does not depend on anything which is not a group member.
I have been thinking about this since seeing this bug: http://bugs.archlinux.org/task/12890 My opinion is that only packages that we directly want in the base group should be in it. Packages that are only needed as deps, should not be in base. That would make package selection in the installer easier too. Allan
On Sun, May 31, 2009 at 7:42 AM, Allan McRae <allan@archlinux.org> wrote:
Pierre Schmitz wrote:
Am Sonntag 31 Mai 2009 14:14:48 schrieb Pierre Schmitz:
If everything is OK we can move both to core and remove lzma-utils from extra.
tpowa just asked me but I am not sure about it: Should cz-utils be part of the base group? It'll be installed anyway because libarchive depends on it. O the other hand we might want to have a base group which does not depend on anything which is not a group member.
I have been thinking about this since seeing this bug: http://bugs.archlinux.org/task/12890
My opinion is that only packages that we directly want in the base group should be in it. Packages that are only needed as deps, should not be in base. That would make package selection in the installer easier too.
Damn, I just replied in the original thread, but I voted the other way. After reading the bug though, I'm not so sure. I guess as long as we don't have [core] depends on [extra] packages I'm satisfied. -Dan
On Sun, May 31, 2009 at 7:30 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Sonntag 31 Mai 2009 14:14:48 schrieb Pierre Schmitz:
If everything is OK we can move both to core and remove lzma-utils from extra.
tpowa just asked me but I am not sure about it: Should cz-utils be part of the base group? It'll be installed anyway because libarchive depends on it. O the other hand we might want to have a base group which does not depend on anything which is not a group member.
Yes, it should. When I originally asked about adding lzma support, we brought up the fact that it would have to be in the base group. -Dan
On Sun, May 31, 2009 at 16:41, Dan McGee<dpmcgee@gmail.com> wrote:
On Sun, May 31, 2009 at 7:30 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Sonntag 31 Mai 2009 14:14:48 schrieb Pierre Schmitz:
If everything is OK we can move both to core and remove lzma-utils from extra.
tpowa just asked me but I am not sure about it: Should cz-utils be part of the base group? It'll be installed anyway because libarchive depends on it. O the other hand we might want to have a base group which does not depend on anything which is not a group member.
Yes, it should. When I originally asked about adding lzma support, we brought up the fact that it would have to be in the base group.
Hm, I don't really see a reason for this, can you explain the reason for me? Here's my logic: a group should not be required to have all dependencies in a group, reason: when installing a group pacman installs all packages as 'explicitly installed' which makes it harder to find no-more-needed dependency in future. Please correct me if I'm wrong about this, since I could forgot something about pacman while being inactive for so long time. Anyway what really bothers me is this: # LANG=C pacman -Su :: Starting full system upgrade... :: Replace lzma-utils with testing/xz-utils? [Y/n] n resolving dependencies... looking for inter-conflicts... :: xz-utils conflicts with lzma-utils. Remove lzma-utils? [Y/n] n error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: xz-utils: conflicts with lzma-utils Why upgrade process breaks here? Is this fixed in pacman 3.3 already? -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
On Sun, May 31, 2009 at 16:41, Dan McGee<dpmcgee@gmail.com> wrote:
On Sun, May 31, 2009 at 7:30 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Sonntag 31 Mai 2009 14:14:48 schrieb Pierre Schmitz:
If everything is OK we can move both to core and remove lzma-utils from extra.
tpowa just asked me but I am not sure about it: Should cz-utils be part of the base group? It'll be installed anyway because libarchive depends on it. O the other hand we might want to have a base group which does not depend on anything which is not a group member.
Yes, it should. When I originally asked about adding lzma support, we brought up the fact that it would have to be in the base group.
Hm, I don't really see a reason for this, can you explain the reason for me? Here's my logic: a group should not be required to have all dependencies in a group, reason: when installing a group pacman installs all packages as 'explicitly installed' which makes it harder to find no-more-needed dependency in future. Please correct me if I'm wrong about this, since I could forgot something about pacman while being inactive for so long time.
I agree. It would also make the list of "base" and "base-devel" packages to select from in the installer much smaller.
Anyway what really bothers me is this: # LANG=C pacman -Su :: Starting full system upgrade... :: Replace lzma-utils with testing/xz-utils? [Y/n] n resolving dependencies... looking for inter-conflicts... :: xz-utils conflicts with lzma-utils. Remove lzma-utils? [Y/n] n error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: xz-utils: conflicts with lzma-utils
Why upgrade process breaks here? Is this fixed in pacman 3.3 already?
That is because you are trying to upgrade libarchive but won't let it install xz-utils. I know it was discussed about pacman removing more packages from a transaction than just the conflicting package to attempt get around these issues but I'm not sure what the actual status is. Allan
On Sun, Jun 7, 2009 at 16:57, Allan McRae<allan@archlinux.org> wrote:
Roman Kyrylych wrote:
Anyway what really bothers me is this: # LANG=C pacman -Su :: Starting full system upgrade... :: Replace lzma-utils with testing/xz-utils? [Y/n] n resolving dependencies... looking for inter-conflicts... :: xz-utils conflicts with lzma-utils. Remove lzma-utils? [Y/n] n error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: xz-utils: conflicts with lzma-utils
Why upgrade process breaks here? Is this fixed in pacman 3.3 already?
That is because you are trying to upgrade libarchive but won't let it install xz-utils. I know it was discussed about pacman removing more packages from a transaction than just the conflicting package to attempt get around these issues but I'm not sure what the actual status is.
Ah, thanks for clarification. Still, it would be good if pacman told user that the problem is with libarchive requiring xz-utils which is impossible to install. Because the current errors are totally confusing. -- Roman Kyrylych (Роман Кирилич)
On Sun, Jun 7, 2009 at 09:57, Allan McRae<allan@archlinux.org> wrote:
Hm, I don't really see a reason for this, can you explain the reason for me? Here's my logic: a group should not be required to have all dependencies in a group, reason: when installing a group pacman installs all packages as 'explicitly installed' which makes it harder to find no-more-needed dependency in future. Please correct me if I'm wrong about this, since I could forgot something about pacman while being inactive for so long time.
I agree. It would also make the list of "base" and "base-devel" packages to select from in the installer much smaller.
Huge +1 from me. I'd really like to see this change.
we had a long discussion about xz/lzma support some time ago. So I finally added xz-utils to testing and rebuild libarchive to make use of it.
:: Replace lzma-utils with localtesting/xz-utils? [Y/n] resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: yelp: requires lzma-utils>=4.32.7
Am Sonntag 31 Mai 2009 15:02:20 schrieb Firmicus:
:: Replace lzma-utils with localtesting/xz-utils? [Y/n]
resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies)
:: yelp: requires lzma-utils>=4.32.7
OK, I a not sure about this. I tried recompiling yelp, but it was not linked against liblzma. So I wonder if it really links against the lib or if it just calls the binary. liblzma has no versioned .so; so I am not sure if a versiond provides would be sane. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Am Sonntag 31 Mai 2009 15:53:26 schrieb Pierre Schmitz:
:: yelp: requires lzma-utils>=4.32.7
OK, I just checked the yelp source. It seems the includes of lzma-utils and xz-utils are different. But on the other side yelp only needs lzma to open lzma compressed info pages. Afaik all our man/info pages are compressed with gzip so it should be safe to compile without lzma support. If I am wrong, please complain. ;-) -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Pierre Schmitz a écrit :
Am Sonntag 31 Mai 2009 15:53:26 schrieb Pierre Schmitz:
:: yelp: requires lzma-utils>=4.32.7
OK, I just checked the yelp source. It seems the includes of lzma-utils and xz-utils are different.
But on the other side yelp only needs lzma to open lzma compressed info pages. Afaik all our man/info pages are compressed with gzip so it should be safe to compile without lzma support.
If I am wrong, please complain. ;-)
It appears you are right and it should be safe to compile yelp without lzma support. We can change that later if e.g. info pages compressed with xz begin to show up. F
Pierre Schmitz schrieb:
Hi devs,
we had a long discussion about xz/lzma support some time ago. So I finally added xz-utils to testing and rebuild libarchive to make use of it.
If everything is OK we can move both to core and remove lzma-utils from extra.
I don't know if anything else has to be recompiled to add support for xz/lzma.
PS: you can build xz archive with bsdtar (part of libarchive). PPS: the git version of pacman/makepkg (future 3.3) should support the xz format (not tested)
bsdtar can create .tar.xz archives with compression level 9 (at least it claims it does, I added --option xz:compression=9 or so) - however, if I unxz them and xz -9 them again (or do that to any tar archives), bsdtar cannot extract them. This is the same for -7 and -8. pacman is therefore also unable to read those archives. No idea why, but I thought I'd mention it.
Thomas Bächler a écrit :
Pierre Schmitz schrieb:
Hi devs,
we had a long discussion about xz/lzma support some time ago. So I finally added xz-utils to testing and rebuild libarchive to make use of it. If everything is OK we can move both to core and remove lzma-utils from extra.
I don't know if anything else has to be recompiled to add support for xz/lzma.
PS: you can build xz archive with bsdtar (part of libarchive). PPS: the git version of pacman/makepkg (future 3.3) should support the xz format (not tested)
bsdtar can create .tar.xz archives with compression level 9 (at least it claims it does, I added --option xz:compression=9 or so) - however, if I unxz them and xz -9 them again (or do that to any tar archives), bsdtar cannot extract them. This is the same for -7 and -8. pacman is therefore also unable to read those archives. No idea why, but I thought I'd mention it.
I've done similar tests a little while ago, and got similar results. I have peeked at the code of bsdtar and if I remember correctly, support for xz appeared to be quite patchy, more a work-in-progress kind of state. Same thing with gnu tar (it has option --lzma to uncompress, but it cannot yet compress). I expected a command for xz/lzma (akin to j for bz2), but neither tar nor bsdtar has such a thing yet. Hopefully this this will be implemented soon, as the xz format is about to become relatively widespread. F
Am Sonntag 31 Mai 2009 22:53:34 schrieb Firmicus:
I expected a command for xz/lzma (akin to j for bz2), but neither tar nor bsdtar has such a thing yet. Hopefully this this will be implemented soon, as the xz format is about to become relatively widespread.
Both, gnu tar and bsdtar support the -J switch to compress and uncompress xz archives. Did you try the recent packages from testing? -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Pierre Schmitz a écrit :
Am Sonntag 31 Mai 2009 22:53:34 schrieb Firmicus:
I expected a command for xz/lzma (akin to j for bz2), but neither tar nor bsdtar has such a thing yet. Hopefully this this will be implemented soon, as the xz format is about to become relatively widespread.
Both, gnu tar and bsdtar support the -J switch to compress and uncompress xz archives. Did you try the recent packages from testing?
Oh neat! I'll try them. Thanks!
Am Sonntag 31 Mai 2009 23:18:17 schrieb Firmicus:
Both, gnu tar and bsdtar support the -J switch to compress and uncompress xz archives. Did you try the recent packages from testin
But it seems that "bsdtar -cf blah.tar.xz blah" just produces an uncompressed tar file. Shouldn't libarchive detect thecompression by the file extension? -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Pierre Schmitz schrieb:
Am Sonntag 31 Mai 2009 23:18:17 schrieb Firmicus:
Both, gnu tar and bsdtar support the -J switch to compress and uncompress xz archives. Did you try the recent packages from testin
But it seems that "bsdtar -cf blah.tar.xz blah" just produces an uncompressed tar file. Shouldn't libarchive detect thecompression by the file extension?
It does, if you specify -J.
On Mon, Jun 1, 2009 at 11:14 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Sonntag 31 Mai 2009 23:18:17 schrieb Firmicus:
Both, gnu tar and bsdtar support the -J switch to compress and uncompress xz archives. Did you try the recent packages from testin
But it seems that "bsdtar -cf blah.tar.xz blah" just produces an uncompressed tar file. Shouldn't libarchive detect thecompression by the file extension?
Both gnu tar and bsdtar automatically detect the compression formats when decompressing an existing archive, but without looking at the file extension. When compressing, they don't look at the extension either, and just default to uncompressed tar. AFAIK, it is exactly the same behavior when you use libarchive directly.
Am Dienstag, 2. Juni 2009 11:47:37 schrieb Xavier:
When compressing, they don't look at the extension either, and just default to uncompressed tar.
Yes, that seems to be right. Even though it looks inconsitent. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
On Sunday 31 May 2009 14:14:48 Pierre Schmitz wrote:
If everything is OK we can move both to core and remove lzma-utils from extra.
Are we ready to move this in? At least one more sign-off would be nice. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Allan McRae a écrit :
Pierre Schmitz wrote:
On Sunday 31 May 2009 14:14:48 Pierre Schmitz wrote:
If everything is OK we can move both to core and remove lzma-utils from extra.
Are we ready to move this in? At least one more sign-off would be nice.
libarchive is working here. Signoff both.
Allan
Same here on i686. Signoff.
participants (9)
-
Allan McRae
-
Daenyth Blank
-
Dan McGee
-
Firmicus
-
Pierre Schmitz
-
Roman Kyrylych
-
Thomas Bächler
-
Tobias Powalowski
-
Xavier