[pacman-dev] Summary of pacman development
This is a quick summary for all of us on the list to see if we are on the same page. I just wanted to get out what we've gotten accomplished in the last month or so, and where we need to go from here to maybe get a pacman 3.1 release pushed out the door. We have had some 272 commits since the version 3.0 tag, so we have gotten some work done, but I don't think any of us are very clear on where the 3.1 release should be. Things we've done: * A lot of makepkg cleanup courtesy of Andrew Fyfe. (http://projects.archlinux.org/git/?p=pacman.git&a=search&st=commit&s=makepkg) * Brought xdelta support into official makepkg- we still need to decide on a strategy for using this if we want to. * Switched to bsdtar usage in makepkg- we no longer depend on the multitude of unzip programs as bsdtar can handle most of them now. * Added several pactests to isolate small issues, most from Nagy Gabor. * Implemented topological support for dependency sorting, courtesy of Nagy Gabor. * Several other small fixes all over the place, and a good amount of code refactoring. * Gettext will now work for our shell scripts- we now have a whole lot more strings that need translating. :) * Bugs closed: http://bugs.archlinux.org/index.php?events%5B%5D=2&event_number=20&project=3&do=reports Things to do: * Pacman and directory symlinks: http://bugs.archlinux.org/task/7484 http://archlinux.org/pipermail/pacman-dev/2007-June/008638.html This is quite the fun little bug. A lot of it deals with our transition both to libarchive, and then to the 2.X branch of libarchive. Andrew has a proposed patch for this problem * Remove CHOST from makepkg.conf? ( http://archlinux.org/pipermail/pacman-dev/2007-July/008662.html) * Fix some bugs related to dependencies: FS 7495, 7416 * FS 7406- NREP umask issue. We should ensure that libalpm and pacman are setting sane umasks for their operations, and we don't get things that have the wrong umask such as db entries. * FS 7193- pacman -D is missing. We should reimplement this as a suboperation of -U such as --asdep or something. It shouldn't be too hard- look at the commit we removed this operation in and revert the parts of it that are necessary, and just use different command line flags. * FS 7137/7133- looks like DB issues * FS 7271- makepkg caching netfiles- should be a super quick fix for someone like Andrew (hint, hint) :) Just look at Roman's last comment * Asciidoc- this is coming along great, Andrew and I have a separate branch for now we are maintaining it in. This should make writing man pages much more pain-free. A few formatting issues probably need working out, but this will also allow us to make much prettier online HTML-formatted documentation. * Current pactests known to fail: requiredby004, sync022, upgrade051. If anyone else on the ML has things to add to this list, please get it out here. Eventually we can lay out a timetable for pacman 3.1 release and start doing some serious testing and regression testing. -Dan
* Remove CHOST from makepkg.conf? ( http://archlinux.org/pipermail/pacman-dev/2007-July/008662.html)
Urgh. I guess still a lot of scripts check this. Or why is the first thing when building a LFS system to set this variable?. And there's more than just configure scripts. There's scons, cmake and some more. And take care that we have used CHOST for some superold stupid scripts where we use CHOST=i686... on x86_64 systems to get it build ;-) I see no need to remove it. Even it nothing will make use of it in the future we should keep it for long. AndyRTR
On 7/9/07, Andreas Radke <a.radke@arcor.de> wrote:
* Remove CHOST from makepkg.conf? ( http://archlinux.org/pipermail/pacman-dev/2007-July/008662.html)
Urgh. I guess still a lot of scripts check this. Or why is the first thing when building a LFS system to set this variable?.
And there's more than just configure scripts. There's scons, cmake and some more.
And take care that we have used CHOST for some superold stupid scripts where we use CHOST=i686... on x86_64 systems to get it build ;-)
I see no need to remove it. Even it nothing will make use of it in the future we should keep it for long.
Well if you look at the thread...right now it isn't doing anything, because makepkg doesn't export it. So it was a two way question, sorry I didn't completely fill it out. It should EITHER be exported OR removed. -Dan
Hello, Na Mon, Jul 09, 2007 at 05:51:58PM -0400, Dan McGee <dpmcgee@gmail.com> pisal(a):
I didn't completely fill it out. It should EITHER be exported OR removed.
the first, but of course it's up to you :) - VMiklos
Well if you look at the thread...right now it isn't doing anything, because makepkg doesn't export it. So it was a two way question, sorry I didn't completely fill it out. It should EITHER be exported OR removed.
-Dan
Here it looks ok and exported: set in makepkg.conf CHOST="x86_64-unknown-linux-gnu" (without export in front) and build() { echo $CHOST } brings: ==> Starting build()... x86_64-unknown-linux-gnu no idea what should be wrong here :S Andy
Hello, Na Tue, Jul 10, 2007 at 12:37:39AM +0200, Andreas Radke <a.radke@arcor.de> pisal(a):
Here it looks ok and exported:
set in makepkg.conf CHOST="x86_64-unknown-linux-gnu" (without export in front)
and build() { echo $CHOST } brings:
==> Starting build()... x86_64-unknown-linux-gnu
no idea what should be wrong here :S
this is ok, but try to echo it from a Makefile, it will be empty - VMiklos
On Mon, Jul 09, 2007 at 05:04:58PM -0400, Dan McGee wrote:
* Added several pactests to isolate small issues, most from Nagy Gabor.
* Implemented topological support for dependency sorting, courtesy of Nagy Gabor.
* Current pactests known to fail: requiredby004, sync022, upgrade051.
Yes, most fix from Nagy have been fixed, but there is a few ones left : * requiredby004 : Nagy UPGRADE RM patch : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008498.html * remove044 pactest (this test hasn't been merged) : Nagy patch for removedeps : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008539.html About sync022, is this a valid pactest ? No one commented on the problem : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008548.html About upgrade051, that's an old pactest which still fails, because it requires merging -A/-U with -S code, and no one is ever going to do that, because it's so messy :)
* Pacman and directory symlinks: http://bugs.archlinux.org/task/7484 http://archlinux.org/pipermail/pacman-dev/2007-June/008638.html This is quite the fun little bug. A lot of it deals with our transition both to libarchive, and then to the 2.X branch of libarchive. Andrew has a proposed patch for this problem
That's probably the most serious issue that needs to be fixed. I proposed a much simpler patch than Andrew's one, but Andrew's way would give us more control on the extraction. That still requires some work though, and then a lot of testing :p
* Fix some bugs related to dependencies: FS 7495, 7416
The second comment on 7495 bug looks to be exactly like Nagy's remove044 pactest, so this test should probably be merged.
If anyone else on the ML has things to add to this list, please get it out here. Eventually we can lay out a timetable for pacman 3.1 release and start doing some serious testing and regression testing.
Well a few issues I tried to investigate : * pacman freeze http://www.archlinux.org/pipermail/pacman-dev/2007-July/008726.html * little error when installing/upgrading the first package in a new db http://www.archlinux.org/pipermail/pacman-dev/2007-July/008693.html Other things that could be done : * various Nagy's various suggestions on dependency handling - refactor search for satisfyer code : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008539.html - usage of alpm_depcmp http://www.archlinux.org/pipermail/pacman-dev/2007-April/007917.html - various stuff http://www.archlinux.org/pipermail/pacman-dev/2007-April/008179.html http://www.archlinux.org/pipermail/pacman-dev/2007-April/008034.html * pmdepend_t / pmdepmissing_t mess : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008539.html Discussion : * the great hashing algorithm discussion : http://www.archlinux.org/pipermail/pacman-dev/2007-March/007775.html http://www.archlinux.org/pipermail/pacman-dev/2007-June/008539.html * format of the database : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008601.html * download code and config parsing in backend or frontend? http://www.archlinux.org/pipermail/pacman-dev/2007-June/008645.html * scriptlets handling http://www.archlinux.org/pipermail/pacman-dev/2007-January/006355.html http://www.archlinux.org/pipermail/pacman-dev/2006-May/005799.html I found a very old TODO from Aurelien in the archives, can anyone comment about the left items : http://www.archlinux.org/pipermail/pacman-dev/2006-March/005700.html hmm, we already had a roadmap for 3.1 :) http://www.archlinux.org/pipermail/pacman-dev/2007-March/007819.html There was also a bug list for 3.1 there : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008624.html but it probably has been outdated by the current thread :)
On Tue, Jul 10, 2007 at 01:15:34AM +0200, Xavier wrote:
The second comment on 7495 bug looks to be exactly like Nagy's remove044 pactest, so this test should probably be merged.
The correct sentence is : The second comment on 7495 bug looks to be exactly like Nagy's requiredby044 pactest, which is already merged (but the patch for it isn't) oh well, I wasn't too far :)
I looked back at this mail for finding an url, and noticed two of them were messed up during copy/pasting :( On Tue, Jul 10, 2007 at 01:15:34AM +0200, Xavier wrote:
* pmdepend_t / pmdepmissing_t mess : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008539.html
That should be : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008649.html
Discussion :
* the great hashing algorithm discussion : http://www.archlinux.org/pipermail/pacman-dev/2007-March/007775.html http://www.archlinux.org/pipermail/pacman-dev/2007-June/008539.html
second link should be : http://www.archlinux.org/pipermail/pacman-dev/2007-July/008672.html
Dan McGee wrote:
* Pacman and directory symlinks: http://bugs.archlinux.org/task/7484 http://archlinux.org/pipermail/pacman-dev/2007-June/008638.html This is quite the fun little bug. A lot of it deals with our transition both to libarchive, and then to the 2.X branch of libarchive. Andrew has a proposed patch for this problem http://neptune-one.homeip.net/git?p=pacman;a=commitdiff;h=2d5a60f480596c2f82...
This is a TEMPORARY fix. From Dan and Xavier's comments in the other thread and my own browsing through the source, ALL backup and conflict checks should be handled BEFORE anything is touched on the users system. At the moment it's very easy to break a users system because we are doing checks as we remove/add files to the system without a way to roll back the changes if something goes wrong.
* Remove CHOST from makepkg.conf? ( http://archlinux.org/pipermail/pacman-dev/2007-July/008662.html) It's seems it's needed by the x86_64 guys, patch to export CHOST http://neptune-one.homeip.net/git?p=pacman;a=commitdiff;h=4259f67bf889f83da5...
* FS 7137/7133- looks like DB issues These are both fixed now I think.
* FS 7271- makepkg caching netfiles- should be a super quick fix for someone like Andrew (hint, hint) :) Just look at Roman's last comment :D http://neptune-one.homeip.net/git?p=pacman;a=commitdiff;h=1ecf75677e9cafa04e...
* Asciidoc- this is coming along great, Andrew and I have a separate branch for now we are maintaining it in. This should make writing man pages much more pain-free. A few formatting issues probably need working out, but this will also allow us to make much prettier online HTML-formatted documentation. I'll try and get this fixed up this week.
Andrew
Andrew Fyfe wrote:
Dan McGee wrote:
* FS 7271- makepkg caching netfiles- should be a super quick fix for someone like Andrew (hint, hint) :) Just look at Roman's last comment :D http://neptune-one.homeip.net/git?p=pacman;a=commitdiff;h=1ecf75677e9cafa04e... That should have been http://neptune-one.homeip.net/git?p=pacman;a=commitdiff;h=5f172a6f3bf354af32...
Andrew
On 7/10/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Andrew Fyfe wrote:
Dan McGee wrote:
* FS 7271- makepkg caching netfiles- should be a super quick fix for someone like Andrew (hint, hint) :) Just look at Roman's last comment :D http://neptune-one.homeip.net/git?p=pacman;a=commitdiff;h=1ecf75677e9cafa04e... That should have been http://neptune-one.homeip.net/git?p=pacman;a=commitdiff;h=5f172a6f3bf354af32...
Only suggestion for this- instead of erroring out if it can't be cached there, can we still fall back to the $startdir for storage? Or better yet- error if $SRCDEST is invalid, but just fall back if $SRCDEST is undefined. I haven't tested your patch enough to see what happens in this case. Other things related to some patches to pull: 1. I cherry-picked the CHOST patch, that is in my working branch now. 2. I had already done some of the changes from your pacman_deptest stuff, see my working branch. It is all now there in two separate commits. -Dan
Dan McGee wrote:
On 7/10/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Andrew Fyfe wrote:
Dan McGee wrote:
* FS 7271- makepkg caching netfiles- should be a super quick fix for someone like Andrew (hint, hint) :) Just look at Roman's last comment :D http://neptune-one.homeip.net/git?p=pacman;a=commitdiff;h=1ecf75677e9cafa04e... That should have been http://neptune-one.homeip.net/git?p=pacman;a=commitdiff;h=5f172a6f3bf354af32...
Only suggestion for this- instead of erroring out if it can't be cached there, can we still fall back to the $startdir for storage? Or better yet- error if $SRCDEST is invalid, but just fall back if $SRCDEST is undefined. I haven't tested your patch enough to see what happens in this case. If SRCDEST isn't passed to makepkg (ie SRCDEST=... makepkg) it defaults to $startdir. So it's always set :)
participants (5)
-
Andreas Radke
-
Andrew Fyfe
-
Dan McGee
-
VMiklos
-
Xavier