[pacman-dev] The time has come- pacman 3.1 testing releases
The time has come. I really want to get pacman 3.1 out the door, and to do that, we need to test this thing a lot. I am currently ONLY supporting i686, and you will need libarchive 2.4.0 installed from testing. However, if anyone on this list would like to step forward and volunteer to build the package for x86_64, I will gladly host the built package. I've provided the PKGBUILD and accompanying files. You can use versionpkg to build this package on your own, or once you have pacman 3.1 installed makepkg has versionpkg functionality built right in so you can just use that to rebuild a new version. Notable changes and things to know: 1. The sync DBs are now in a sync/ subdir in your pacman DB directory. Thus, the old top-level dbs are obsolete. This should hopefully clearly separate the local and sync dbs and keep people from wiping that important local one. 2. I WOULD NOT recommend using the --root option at this point. I still need to make some fixes, and its behavior wrt other path options is a lot different than pacman 3.0.X. 3. Consolidated mirrorlists- you don't need 5 of them anymore. See below for a bit more info on this, and take a look at the installed /etc/pacman.conf and /etc/pacman.d/mirrorlist files. So without further ado, instructions for upgrading/testing (PLEASE read all instructions before actually doing the upgrade!): 1. Because this package will replace your stock pacman, you either need to put the package in your own local repo, or add my [pacman] repo to your pacman.conf. The second is probably a safer bet and will allow you to get updates I make to the package anyway. Once you add the repo, the package name is pacman-git. 2. Once installed, you will see that you get a whole bunch of pacsave files. A lot of these are related to the mirrorlists being consolidated into one "mirrorlist" file instead of having 5 separate but basically identical lists. I kept these on my system just so I can use the pacman2.static binary if something goes horribly wrong. (Of course, you would have to remove the pacsave extension from all of these files to use them). 3. A pacman2.static binary has been included in the package, just in case. Hopefully no one needs to use it. 4. One issue is kind of weird, and may be a bug in the way we do replaces handling. Your original pacman.conf will be moved to pacman.conf.pacsave, and the new one installed as pacman.conf. Of course, you will need to do some merging of the config files, but unfortunately they end up backwards from the norm. 5. Point 4 also applies for makepkg.conf, but the contents of this file have changed enough that you should probably just start a new one anyway. A note to testers- please let me know if anything in your upgrade path is different from above. This will really help us later when it comes to finalizing the real upgrade path. And if you hit a problem, please submit a full report to the mailling list and/or Flyspray (this means a descriptive title, steps to reproduce, and --debug output). I have this installed, so don't worry too much about it killing your system. :P And now the links and stuff: Package/DB: http://www.archlinux.org/~dan/pacman-git/ PKGBUILD/files: http://www.archlinux.org/~dan/pacman-git/pacman-git/ pacman.conf entry: [pacman-git] Server = http://www.archlinux.org/~dan/pacman-git/ -Dan
On Nov 5, 2007 10:58 PM, Dan McGee <dpmcgee@gmail.com> wrote:
A note to testers- please let me know if anything in your upgrade path is different from above. This will really help us later when it comes to finalizing the real upgrade path. And if you hit a problem, please submit a full report to the mailling list and/or Flyspray (this means a descriptive title, steps to reproduce, and --debug output).
Forgot to mention- we'd love to hear from those of you that are using it without problems as well! That way we know there are more than 3 of us actually using it and can feel a lot more confident when it comes close to releasing. -Dan
On 11/5/07, Dan McGee <dpmcgee@gmail.com> wrote:
I have this installed, so don't worry too much about it killing your system. :P
Aside from a quirk where libarchive wasn't upgraded here[1] on pacman -Sy pacman-git, pacman-git itself installed fine and is running without a hitch. Scott [1] pacman.log: [2007-11-05 22:02] upgraded libarchive (2.2.6-2 -> 2.2.6-2)
On Mon, Nov 05, 2007 at 10:32:41PM -0700, Scott Horowitz wrote:
On 11/5/07, Dan McGee <dpmcgee@gmail.com> wrote:
I have this installed, so don't worry too much about it killing your system. :P
Aside from a quirk where libarchive wasn't upgraded here[1] on pacman -Sy pacman-git, pacman-git itself installed fine and is running without a hitch.
Scott
[1] pacman.log: [2007-11-05 22:02] upgraded libarchive (2.2.6-2 -> 2.2.6-2)
Hmm yes, that's a funny bug :) pacman 3.0 see the libarchive>=2.4.0 is not satisfied, and then it pulls libarchive without even checking it's the correct version. That's exactly the kind of negligency in the dependencies checking/resolving that Nagy fixed, so probably this one too :) This is what happens when doing the above with 3.1 : resolving dependencies... error: cannot resolve "libarchive>=2.4.0", a dependency of "pacman-git" error: failed to prepare transaction (could not satisfy dependencies) :: pacman-git: requires libarchive>=2.4.0 So it fails, as expected. You have to enable the testing repo or update libarchive manually :) Bug already fixed.
On Mon, Nov 05, 2007 at 10:58:03PM -0600, Dan McGee wrote:
1. Because this package will replace your stock pacman, you either need to put the package in your own local repo, or add my [pacman] repo to your pacman.conf.
Hm, that TODO again :)
4. One issue is kind of weird, and may be a bug in the way we do replaces handling. Your original pacman.conf will be moved to pacman.conf.pacsave, and the new one installed as pacman.conf. Of course, you will need to do some merging of the config files, but unfortunately they end up backwards from the norm.
Well, it's not an upgrade here. Even though in this particular case, it's the same package, in the general replace case, I don't think the new package has to have the same files than the old one. I think it just has to provide the same functionality. So pacman just removes the "to be replaced package", generating all these .pacsave files, and then it installs the new one. Everything behaves as expected. But maybe pacman could handle replacement just like an upgrade, and try handling the backup files the same way,.. I'm not sure. I'm just saying that there are no bugs here in my opinion :)
On Nov 6, 2007 3:35 PM, Xavier <shiningxc@gmail.com> wrote:
On Mon, Nov 05, 2007 at 10:58:03PM -0600, Dan McGee wrote:
4. One issue is kind of weird, and may be a bug in the way we do replaces handling. Your original pacman.conf will be moved to pacman.conf.pacsave, and the new one installed as pacman.conf. Of course, you will need to do some merging of the config files, but unfortunately they end up backwards from the norm.
Well, it's not an upgrade here. Even though in this particular case, it's the same package, in the general replace case, I don't think the new package has to have the same files than the old one. I think it just has to provide the same functionality.
Yeah, you beat me here. I said this on IRC to Dan - the problem is that 'pacman' is removed, which emits all the pacsave files, then pacman-git is installed. Curious (not at home) - does pacman-git provide=(pacman) ?
On Nov 6, 2007 3:55 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Yeah, you beat me here. I said this on IRC to Dan - the problem is that 'pacman' is removed, which emits all the pacsave files, then pacman-git is installed.
Curious (not at home) - does pacman-git provide=(pacman) ?
$ pacman -Qi pacman-git Name : pacman-git Version : 20071105-1 URL : http://www.archlinux.org/pacman/ License : GPL Groups : None Provides : pacman Depends On : gcc-libs bash libarchive>=2.4.0 libdownload Optional Deps : None Required By : pacsearch srcpac Conflicts With : pacman Replaces : None Installed Size : 3220.71 K Packager : Dan McGee <dan@archlinux.org> Architecture : i686 Build Date : Mon Nov 5 22:14:30 2007 Install Date : Mon Nov 5 22:15:11 2007 Install Reason : Explicitly installed Install Script : No Description : A library-based package manager with dependency support
On Mon, Nov 05, 2007 at 10:58:03PM -0600, Dan McGee wrote:
PKGBUILD/files: http://www.archlinux.org/~dan/pacman-git/pacman-git/
I had two questions about depends and makedepends I forgot to ask :P 1) what's up with fakeroot? It was a dependency of pacman 3.0 and previous pacman 3.1 pkgbuild, but it's gone now. I may have read a discussion about this earlier, but totally forgot now.. 2) I believe docbook-xsl should be added to makedepends If I remember correctly, this is not a big problem, since in the final PKGBUILD, building of manpage will be disabled, but I mention it just in case. Sorry if these two questions are stupid :)
On Nov 6, 2007 4:03 PM, Xavier <shiningxc@gmail.com> wrote:
On Mon, Nov 05, 2007 at 10:58:03PM -0600, Dan McGee wrote:
PKGBUILD/files: http://www.archlinux.org/~dan/pacman-git/pacman-git/
I had two questions about depends and makedepends I forgot to ask :P
1) what's up with fakeroot? It was a dependency of pacman 3.0 and previous pacman 3.1 pkgbuild, but it's gone now. I may have read a discussion about this earlier, but totally forgot now..
We don't want to require users to have "development" tools on their machines, and fakeroot falls into this category. pacman itself doesn't require it, but makepkg does if you run it as a non-root user. Perhaps I should put our optdepends array to early good use, at least to test what I've implemented so far?
2) I believe docbook-xsl should be added to makedepends If I remember correctly, this is not a big problem, since in the final PKGBUILD, building of manpage will be disabled, but I mention it just in case.
Good catch, added. Clarification on the above- in the final package, asciidoc will not be required, but it will also not be disabled. The 'make dist' target is set up to include the built manpages in the dist tarball, so an end user building the package won't need to do this themselves. I feel like we should do the doxygen manpages this way as well...I'll look into that and then we can remove that as a makedepend. -Dan
On Tue, Nov 06, 2007 at 04:13:50PM -0600, Dan McGee wrote:
We don't want to require users to have "development" tools on their machines, and fakeroot falls into this category. pacman itself doesn't require it, but makepkg does if you run it as a non-root user.
Ok, fair enough.
Perhaps I should put our optdepends array to early good use, at least to test what I've implemented so far?
Probably a good idea then.
Good catch, added. Clarification on the above- in the final package, asciidoc will not be required, but it will also not be disabled. The 'make dist' target is set up to include the built manpages in the dist tarball, so an end user building the package won't need to do this themselves. I feel like we should do the doxygen manpages this way as well...I'll look into that and then we can remove that as a makedepend.
Alright.
On Mon, Nov 05, 2007 at 10:58:03PM -0600, Dan McGee wrote:
PKGBUILD/files: http://www.archlinux.org/~dan/pacman-git/pacman-git/
git should be added to makedepends. Will the color patch make it into 3.1? I know you had a color branch in your tree, but I cannot find it now.
On Nov 6, 2007 4:24 PM, Nathan Jones <nathanj@insightbb.com> wrote:
On Mon, Nov 05, 2007 at 10:58:03PM -0600, Dan McGee wrote:
PKGBUILD/files: http://www.archlinux.org/~dan/pacman-git/pacman-git/
git should be added to makedepends.
Hah, he got you there Dan!
Will the color patch make it into 3.1? I know you had a color branch in your tree, but I cannot find it now.
Hmm. I haven't seen an updated patch for this in ages, unless Dan's been keeping up on it. I'd love to see it at some point, but we'd need a cleaner implementation than using terminal escapes.
On Nov 6, 2007 4:37 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Nov 6, 2007 4:24 PM, Nathan Jones <nathanj@insightbb.com> wrote:
On Mon, Nov 05, 2007 at 10:58:03PM -0600, Dan McGee wrote:
PKGBUILD/files: http://www.archlinux.org/~dan/pacman-git/pacman-git/
git should be added to makedepends.
Hah, he got you there Dan!
Will the color patch make it into 3.1? I know you had a color branch in your tree, but I cannot find it now.
Hmm. I haven't seen an updated patch for this in ages, unless Dan's been keeping up on it.
I'd love to see it at some point, but we'd need a cleaner implementation than using terminal escapes.
I still have this as a local branch in my local GIT tree...if anyone else wants to do a big rebase, let me know. I was doing it for a while but then I dropped behind. I'll push it back out to my public repo tonight. -Dan
The time has come. I really want to get pacman 3.1 out the door, and to do that, we need to test this thing a lot.
I am currently ONLY supporting i686, and you will need libarchive 2.4.0 installed from testing. However, if anyone on this list would like to step forward and volunteer to build the package for x86_64, I will gladly host the built package.
I've provided the PKGBUILD and accompanying files. You can use versionpkg to build this package on your own, or once you have pacman 3.1 installed makepkg has versionpkg functionality built right in so you can just use that to rebuild a new version.
Notable changes and things to know: 1. The sync DBs are now in a sync/ subdir in your pacman DB directory. Thus, the old top-level dbs are obsolete. This should hopefully clearly separate the local and sync dbs and keep people from wiping that important local one. 2. I WOULD NOT recommend using the --root option at this point. I still need to make some fixes, and its behavior wrt other path options is a lot different than pacman 3.0.X. 3. Consolidated mirrorlists- you don't need 5 of them anymore. See below for a bit more info on this, and take a look at the installed /etc/pacman.conf and /etc/pacman.d/mirrorlist files.
So without further ado, instructions for upgrading/testing (PLEASE read all instructions before actually doing the upgrade!):
1. Because this package will replace your stock pacman, you either need to put the package in your own local repo, or add my [pacman] repo to your pacman.conf. The second is probably a safer bet and will allow you to get updates I make to the package anyway. Once you add the repo, the package name is pacman-git.
2. Once installed, you will see that you get a whole bunch of pacsave files. A lot of these are related to the mirrorlists being consolidated into one "mirrorlist" file instead of having 5 separate but basically identical lists. I kept these on my system just so I can use the pacman2.static binary if something goes horribly wrong. (Of course, you would have to remove the pacsave extension from all of these files to use them).
3. A pacman2.static binary has been included in the package, just in case. Hopefully no one needs to use it.
4. One issue is kind of weird, and may be a bug in the way we do replaces handling. Your original pacman.conf will be moved to pacman.conf.pacsave, and the new one installed as pacman.conf. Of course, you will need to do some merging of the config files, but unfortunately they end up backwards from the norm.
5. Point 4 also applies for makepkg.conf, but the contents of this file have changed enough that you should probably just start a new one anyway.
A note to testers- please let me know if anything in your upgrade path is different from above. This will really help us later when it comes to finalizing the real upgrade path. And if you hit a problem, please submit a full report to the mailling list and/or Flyspray (this means a descriptive title, steps to reproduce, and --debug output).
I have this installed, so don't worry too much about it killing your system. :P
And now the links and stuff: Package/DB: http://www.archlinux.org/~dan/pacman-git/ PKGBUILD/files: http://www.archlinux.org/~dan/pacman-git/pacman-git/
pacman.conf entry: [pacman-git] Server = http://www.archlinux.org/~dan/pacman-git/
-Dan
Some really small TODOs to mention for 3.1: -update bash_completion (add --asdeps for example) -the documentation of -S and -R needs some updates too (groups and provisions aren't mentioned in man): in more general most of the libalpm specific stuffs are undocumented (someone should "fast-read" the source(comments) and document it) Bye PS: a bigger TODO: %REASON% handling should be fixed imho, before final release. ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
participants (6)
-
Aaron Griffin
-
Dan McGee
-
Nagy Gabor
-
Nathan Jones
-
Scott Horowitz
-
Xavier