[arch-dev-public] Moving to pkg.tar.xz officially?
Hi all, some of us already commit xz compressed packages, others don't. We didn't really decide on this yet. So, is there a reason not to recommond every TU and Dev to change PKGEXT to .pkg.tar.xz? We might also want to write a little announcement to inform users about this change. While most of them wont be affected, some would have to adjust their custom scripts. And for those who use netinstall on a 2009.02 or older iso would have to run pacman -Syu once to get a version of libarchive which is able to deal with xz. If wanted I also could add a check to devtools which issues a warning if xz is not used. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
Il 09/03/2010 08:16, Pierre Schmitz ha scritto:
So, is there a reason not to recommond every TU and Dev to change PKGEXT to .pkg.tar.xz?
I just switched to .pkg.tar.xz Can we switch to .pkg.tar.xz for community too? -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it
Am 09.03.2010 14:41, schrieb Giovanni Scafora:
Il 09/03/2010 08:16, Pierre Schmitz ha scritto:
So, is there a reason not to recommond every TU and Dev to change PKGEXT to .pkg.tar.xz?
I just switched to .pkg.tar.xz Can we switch to .pkg.tar.xz for community too?
Other TUs have already done so as far as I know. dbscripts on sigurd have been updated to support .xz. You should be fine.
On Tue, 2010-03-09 at 08:16 +0100, Pierre Schmitz wrote:
Hi all,
some of us already commit xz compressed packages, others don't. We didn't really decide on this yet.
So, is there a reason not to recommond every TU and Dev to change PKGEXT to .pkg.tar.xz?
We might also want to write a little announcement to inform users about this change. While most of them wont be affected, some would have to adjust their custom scripts. And for those who use netinstall on a 2009.02 or older iso would have to run pacman -Syu once to get a version of libarchive which is able to deal with xz.
If we do this, we should leave pacman and libarchive in a historic format for quite a while (or forever). Those packages are already small enough it doesn't really matter. Dale
On Tue, Mar 9, 2010 at 7:54 AM, Dale Blount
On Tue, 2010-03-09 at 08:16 +0100, Pierre Schmitz wrote:
Hi all,
some of us already commit xz compressed packages, others don't. We didn't really decide on this yet.
So, is there a reason not to recommond every TU and Dev to change PKGEXT to .pkg.tar.xz?
We might also want to write a little announcement to inform users about this change. While most of them wont be affected, some would have to adjust their custom scripts. And for those who use netinstall on a 2009.02 or older iso would have to run pacman -Syu once to get a version of libarchive which is able to deal with xz.
If we do this, we should leave pacman and libarchive in a historic format for quite a while (or forever). Those packages are already small enough it doesn't really matter.
I was going to respond to this thread and say we should keep a small subset of packages in tar.gz format for things like this. Most of them happen to be mine, but: * pacman * libarchive * libfetch * zlib ? * glibc ? * bash ? -Dan
We might also want to write a little announcement to inform users about this change. While most of them wont be affected, some would have to adjust their custom scripts. And for those who use netinstall on a 2009.02 or older iso would have to run pacman -Syu once to get a version of libarchive which is able to deal with xz.
If we do this, we should leave pacman and libarchive in a historic format for quite a while (or forever). Those packages are already small enough it doesn't really matter.
I was going to respond to this thread and say we should keep a small subset of packages in tar.gz format for things like this. Most of them happen to be mine, but: * pacman * libarchive * libfetch * zlib ? * glibc ? * bash ?
+1. At some point pacman is going to need a glibc update to work and not being able to install glibc because it's a xz is an issue. We should probably add a versioned glibc to pacman's depends so someone doesn't end up upgrading pacman and not being able to run it because glibc didn't get updated as well. Dale
On Tue, Mar 9, 2010 at 09:23, Dale Blount
I was going to respond to this thread and say we should keep a small subset of packages in tar.gz format for things like this. Most of them happen to be mine, but: * pacman * libarchive * libfetch * zlib ? * glibc ? * bash ?
+1. At some point pacman is going to need a glibc update to work and not being able to install glibc because it's a xz is an issue. We should probably add a versioned glibc to pacman's depends so someone doesn't end up upgrading pacman and not being able to run it because glibc didn't get updated as well.
Dale
+1 to everything here. Will it work if we set PKGEXT in the PKGBUILD itself with a comment so that it overrides makepkg.conf?
Am 09.03.2010 15:23, schrieb Dale Blount:
+1. At some point pacman is going to need a glibc update to work and not being able to install glibc because it's a xz is an issue. We should probably add a versioned glibc to pacman's depends so someone doesn't end up upgrading pacman and not being able to run it because glibc didn't get updated as well.
Dale
Newer glibc needs a newer kernel quite often, so you end up having half of core as non-xz (a rule which has already been violated right now). Even the 2009.08 image should have xz support already (with a bug that fails to extract xz -9 packages but not xz -6 packages), so we should be okay, mostly.
On Tue, Mar 9, 2010 at 09:41, Thomas Bächler
Newer glibc needs a newer kernel quite often, so you end up having half of core as non-xz (a rule which has already been violated right now).
Maybe we should set a timeline that says "after this date, we will not provide .gz pacman+toolchain?" Set it far enough in the future that it doesn't matter. I think the only people who might run into issues are some VPS providers who may have an old install iso. We should also contact them and tell them to update their junk
Am Dienstag, 9. März 2010 15:18:47 schrieb Dan McGee:
I was going to respond to this thread and say we should keep a small subset of packages in tar.gz format for things like this. Most of them happen to be mine, but: * pacman * libarchive * libfetch * zlib ? * glibc ? * bash ?
This might got lost in the other threads but I already took care of this. I have set PKGEXT to .pkg.tar.gz within the PKGBUILD for pacman, libarchive, xz- utils and libfetch. If you run pacman -Syu on an old system, pacman will update those at first and quit. On the next run you already have a xz- compatible pacman. I have successfully tested this with the 2009.02 iso and I am sure it will work with even older versions. And to be honest: if you only update every one or two years you shouldn't use Arch anyway. (or you know what you are doing and are able to take care of the problems you get then.) -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 10/03/10 03:38, Pierre Schmitz wrote:
Am Dienstag, 9. März 2010 15:18:47 schrieb Dan McGee:
I was going to respond to this thread and say we should keep a small subset of packages in tar.gz format for things like this. Most of them happen to be mine, but: * pacman * libarchive * libfetch * zlib ? * glibc ? * bash ?
This might got lost in the other threads but I already took care of this. I have set PKGEXT to .pkg.tar.gz within the PKGBUILD for pacman, libarchive, xz- utils and libfetch. If you run pacman -Syu on an old system, pacman will update those at first and quit. On the next run you already have a xz- compatible pacman.
I have successfully tested this with the 2009.02 iso and I am sure it will work with even older versions.
And to be honest: if you only update every one or two years you shouldn't use Arch anyway. (or you know what you are doing and are able to take care of the problems you get then.)
So... are people happy with me compressing the upcoming toolchain rebuild with xz? There are no versioned deps between pacman or any of its deps and the toolchain. That means the initial upgrade to pacman when upgrading a system will not be affected by this. If that ever changes, I will switch back. Allan
Am Dienstag, 9. März 2010 22:39:57 schrieb Allan McRae:
So... are people happy with me compressing the upcoming toolchain rebuild with xz? There are no versioned deps between pacman or any of its deps and the toolchain. That means the initial upgrade to pacman when upgrading a system will not be affected by this. If that ever changes, I will switch back.
I just downloaded the 2008.06 iso and could successfully issue an -Syu. (I have now added pacman-mirrorlist to the packages that should be kept in gz format) I also tried a iso from 2007 but that kernel glibc wasn't compatible. But such an old setup could only be updated from a newer live cd anyway. In other words: the current solutions ensures that there is still a smooth update path for systems that haven't seen an -Syu for about two years. I really don't think we should worry here. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, Mar 10, 2010 at 6:15 AM, Pierre Schmitz
Am Dienstag, 9. März 2010 22:39:57 schrieb Allan McRae:
So... are people happy with me compressing the upcoming toolchain rebuild with xz? There are no versioned deps between pacman or any of its deps and the toolchain. That means the initial upgrade to pacman when upgrading a system will not be affected by this. If that ever changes, I will switch back.
I just downloaded the 2008.06 iso and could successfully issue an -Syu. (I have now added pacman-mirrorlist to the packages that should be kept in gz format)
I also tried a iso from 2007 but that kernel glibc wasn't compatible. But such an old setup could only be updated from a newer live cd anyway.
In other words: the current solutions ensures that there is still a smooth update path for systems that haven't seen an -Syu for about two years. I really don't think we should worry here.
Awesome- thanks for looking into this, Pierre. -Dan
FYI: devtools-0.9.5 should be able to upload any compressed package no matter which PKGEXT is set on the host. This way you can still use devtools for those packages that remain in gz format. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Dienstag, 9. März 2010 08:16:42 schrieb Pierre Schmitz:
some of us already commit xz compressed packages, others don't. We didn't really decide on this yet.
As there are no further complains, I'll write a draft news item about this. Some devs/tus still submit gz packages so I guess not everybody knew about this. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Samstag, 20. März 2010 14:28:00 schrieb Pierre Schmitz:
Am Dienstag, 9. März 2010 08:16:42 schrieb Pierre Schmitz:
some of us already commit xz compressed packages, others don't. We didn't really decide on this yet.
As there are no further complains, I'll write a draft news item about this. Some devs/tus still submit gz packages so I guess not everybody knew about this.
Andy ask me if we shouldn't set this in the default makepkg.conf provided by pacman. It's probably not worth to release a new package just for this, but it might be for future versions. What do you think? -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 20/03/10 23:49, Pierre Schmitz wrote:
Am Samstag, 20. März 2010 14:28:00 schrieb Pierre Schmitz:
Am Dienstag, 9. März 2010 08:16:42 schrieb Pierre Schmitz:
some of us already commit xz compressed packages, others don't. We didn't really decide on this yet.
As there are no further complains, I'll write a draft news item about this. Some devs/tus still submit gz packages so I guess not everybody knew about this.
Andy ask me if we shouldn't set this in the default makepkg.conf provided by pacman. It's probably not worth to release a new package just for this, but it might be for future versions.
What do you think?
I see no reason against setting this as default and agree that it is not worth repackaging for that. Allan
On Saturday 20 March 2010 14:53:48 Allan McRae wrote:
I see no reason against setting this as default and agree that it is not worth repackaging for that. quote
-- Andrea
Am Samstag, 20. März 2010 14:53:48 schrieb Allan McRae:
Andy ask me if we shouldn't set this in the default makepkg.conf provided by pacman. It's probably not worth to release a new package just for this, but it might be for future versions.
What do you think?
I see no reason against setting this as default and agree that it is not worth repackaging for that.
I just commited this to svn/trunk. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Tue, Mar 23, 2010 at 1:09 PM, Pierre Schmitz
Am Samstag, 20. März 2010 14:53:48 schrieb Allan McRae:
Andy ask me if we shouldn't set this in the default makepkg.conf provided by pacman. It's probably not worth to release a new package just for this, but it might be for future versions.
What do you think?
I see no reason against setting this as default and agree that it is not worth repackaging for that.
I just commited this to svn/trunk.
Thanks.
participants (8)
-
Allan McRae
-
Andrea Scarpino
-
Daenyth Blank
-
Dale Blount
-
Dan McGee
-
Giovanni Scafora
-
Pierre Schmitz
-
Thomas Bächler