[pacman-dev] Roadmap for 3.1
Looks like it's time to move towards a 3.1 release. Dan and I both have a lot of items listed in our TODO lists, though most of them are code changes (doesn't affect the end user much). So I'd like to open the floor up for ideas - what *functional* changes interest you all, as a user of pacman? I'm going to take some input here, and then compose a list of what I'd like to do for the 3.1 release. Keep in mind that, going forward, I'd like to do quick, smaller releases (every 1-2 months would be ideal) so not everything will get done right away. Also, as a side note, we're probably going to be moving to using git for development - making it easier for other users to contribute patches and things like that (still kinda pending on some side projects I'm working on, but I digress). Anyway, let me know. Thanks, Aaron
Aaron Griffin wrote:
Looks like it's time to move towards a 3.1 release. Dan and I both have a lot of items listed in our TODO lists, though most of them are code changes (doesn't affect the end user much).
So I'd like to open the floor up for ideas - what *functional* changes interest you all, as a user of pacman?
I'm going to take some input here, and then compose a list of what I'd like to do for the 3.1 release.
Keep in mind that, going forward, I'd like to do quick, smaller releases (every 1-2 months would be ideal) so not everything will get done right away.
Also, as a side note, we're probably going to be moving to using git for development - making it easier for other users to contribute patches and things like that (still kinda pending on some side projects I'm working on, but I digress).
Anyway, let me know.
Thanks, Aaron
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
Cleanup scripts/* - move msg* error warning in_array check_* out of makepkg so all scripts can make use of them. - use tput for coloured output - move BUILDSCRIPT PKGEXT DB_COMPRESSION into makepkg.conf - gettext support (Giovanni Scafora has done some work on this) - move pacman.lck to /var/run (that's where lock files belong) Andrew
Comments and some of my own stuff here. On 3/28/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Aaron Griffin wrote:
Looks like it's time to move towards a 3.1 release. Dan and I both have a lot of items listed in our TODO lists, though most of them are code changes (doesn't affect the end user much).
So I'd like to open the floor up for ideas - what *functional* changes interest you all, as a user of pacman?
I'm going to take some input here, and then compose a list of what I'd like to do for the 3.1 release.
Keep in mind that, going forward, I'd like to do quick, smaller releases (every 1-2 months would be ideal) so not everything will get done right away.
Also, as a side note, we're probably going to be moving to using git for development - making it easier for other users to contribute patches and things like that (still kinda pending on some side projects I'm working on, but I digress).
Cleanup scripts/* - move msg* error warning in_array check_* out of makepkg so all scripts can make use of them. - use tput for coloured output - move BUILDSCRIPT PKGEXT DB_COMPRESSION into makepkg.conf - gettext support (Giovanni Scafora has done some work on this)
Yes, I like most of this, and it would be good to see in 3.1. Especially if patches start rolling in.
- move pacman.lck to /var/run (that's where lock files belong)
Easy fix, so we can definitely do this, and it makes sense. The only issue may be when a non-root user is running pacman and using --root, but in that case the whole filesystem they are writing too should have different permissions anyway. My list, which may duplicate things above: * Resolve issues with permissions checking. Instead of flat-out requiring root, we should do smart permissions checking- can the user write here? Can they view this? etc. * Gettext support in makepkg, and clean up the way we use gettext. We really don't need any debug message in libalpm translated, and the ideal would be to keep all translation to the front end pacman part. * Fakeroot patches and improvement for makepkg. Thanks Andrew! * A few other local/i18n issues- notably the progress bar being in the wrong place, etc. * Standardized exit codes for pacman and makepkg. These should be set, documented, and utilized in scripts that look at output codes. Way down the line is function cleanup- libalpm has a lot of duplication and functions that are not documented well at all, and we should change that. -Dan
Dan McGee wrote:
Comments and some of my own stuff here.
On 3/28/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Cleanup scripts/* - move msg* error warning in_array check_* out of makepkg so all scripts can make use of them. - use tput for coloured output - move BUILDSCRIPT PKGEXT DB_COMPRESSION into makepkg.conf - gettext support (Giovanni Scafora has done some work on this)
Yes, I like most of this, and it would be good to see in 3.1. Especially if patches start rolling in.
Now that I've got the hang of git, I start knocking up some patches for these.
* Standardized exit codes for pacman and makepkg. These should be set, documented, and utilized in scripts that look at output codes. I've made a start on makepkg. I'm aiming to replace all the exit's with $E_* so it's easier to work out why makepkg is exiting. So far I've got 0 = E_OK - No error. 1 = E_UNKNOWN - This is should be avoided where ever possible. 2 = E_BUILD_FAILED - build() failed for some reason. 4 = E_USER_ABORT - do I need to explain :p 8 = E_MISSING_PROGRAM - if wget|fakeroot|... are missing. 16 = E_CONFIG_ERROR - something wrong (or missing) with makepkg.conf. 32 = E_BUILDSCRIPT_ERROR - something wrong (or missing) with PKGBUILD.
Andrew
Aaron Griffin wrote:
Also, as a side note, we're probably going to be moving to using git for development - making it easier for other users to contribute patches and things like that (still kinda pending on some side projects I'm working on, but I digress).
For those that don't have a clue about git (like me :p) you might want to start here >> http://www.kernel.org/pub/software/scm/git/docs/tutorial.html Andrew
On 3/28/07, Andrew Fyfe <andrew@neptune-one.net> wrote:
Aaron Griffin wrote:
Also, as a side note, we're probably going to be moving to using git for development - making it easier for other users to contribute patches and things like that (still kinda pending on some side projects I'm working on, but I digress).
For those that don't have a clue about git (like me :p) you might want to start here >> http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
Andrew
And we should have a public tree on archlinux.org very soon, but until then you can pull from my tree (which will always mirror the main tree plus having a few of my branches). <http://code.toofishes.net/gitweb.cgi> will allow you to browse the tree, and the actual URL to use for a 'git clone' operation is <http://code.toofishes.net/gitprojects/pacman.git/>. -Dan
2007/3/28, Dan McGee <dpmcgee@gmail.com>:
And we should have a public tree on archlinux.org very soon, but until then you can pull from my tree (which will always mirror the main tree plus having a few of my branches). <http://code.toofishes.net/gitweb.cgi> will allow you to browse the tree, and the actual URL to use for a 'git clone' operation is <http://code.toofishes.net/gitprojects/pacman.git/>.
I'm unable to get the git code. I'm trying with: git clone http://code.toofishes.net/gitprojects/pacman.git/ but I have got the following message: error: Unable to find b948da308a2d8f33738ffa300464c6ca5804a3ef under http://code.toofishes.net/gitprojects/pacman.git// Cannot obtain needed object b948da308a2d8f33738ffa300464c6ca5804a3ef Some loose object were found to be corrupt, but they might be just a false '404 Not Found' error message sent with incorrect HTTP status code. Suggest running git-fsck. -- Giovanni Scafora Arch Linux Trusted User (voidnull) http://www.archlinux.org linuxmania@gmail.com
On 3/28/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Looks like it's time to move towards a 3.1 release. Dan and I both have a lot of items listed in our TODO lists, though most of them are code changes (doesn't affect the end user much).
Here we go, here's a roadmap for what I want to work on OVERALL CHANGES --------------- * Fully transition to git CODE CHANGES ------------ * Revamp the current transaction setup. Proposed: alpm_trans_commit(pkgs_to_install, pkgs_to_remove) All conflict checking, freespace checking, etc should be done with non-transactional functions, such as a alpm_get_upgrades() * New list type? Either way, I'd like to create distinct "package list" and "string list" types * Clean up some excess backend types (i.e. pmdepmissing_t) * Add a pm_errstr compliment to pm_errno for libalpm textual errors (Apply gettext at the pacman level??) * Move some libalpm function names/locations - No need to have alpm.c, move the public functions to the proper files - alpm_*_get_* functions probably don't need the "_get" part, as it's implied (MINOR) * Rework libalpm -> frontend communication (question, event, and progess) * Combine a handful of single-function src/pacman headers (i.e. sync.h) FUNCTIONAL CHANGES ------------------ * Attempt to rebuild a corrupt DB entry if found * Combine -U/-A code with -S code - Fix the "replacement" on -U/-A * Other bugs/FRs in flyspray??
On Wed, 28 Mar 2007 10:46:43 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
Looks like it's time to move towards a 3.1 release. Dan and I both have a lot of items listed in our TODO lists, though most of them are code changes (doesn't affect the end user much).
So I'd like to open the floor up for ideas - what *functional* changes interest you all, as a user of pacman?
It's been brought up before, but I'd like to mention it - standardization of pre/post-install/remove messages in the .install file. Some kind of function that'll nicely format these messages, with the possibility to have them recorded to the pacman log as well, would be very useful. -- Travis
On 3/29/07, Travis Willard <travisw@wmpub.ca> wrote:
On Wed, 28 Mar 2007 10:46:43 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
Looks like it's time to move towards a 3.1 release. Dan and I both have a lot of items listed in our TODO lists, though most of them are code changes (doesn't affect the end user much).
So I'd like to open the floor up for ideas - what *functional* changes interest you all, as a user of pacman?
It's been brought up before, but I'd like to mention it - standardization of pre/post-install/remove messages in the .install file. Some kind of function that'll nicely format these messages, with the possibility to have them recorded to the pacman log as well, would be very useful.
Yeah good one. For the record, though, pacman 3 does log all that output.
It's been brought up before, but I'd like to mention it - standardization of pre/post-install/remove messages in the .install file. Some kind of function that'll nicely format these messages, with the possibility to have them recorded to the pacman log as well, would be very useful.
Yeah good one. For the record, though, pacman 3 does log all that output.
Whoohoo, that's my FR :) http://bugs.archlinux.org/task/1571 We of course couldn't start using it until we were sure there weren't any pacman2/makepkg2 users left which could take quite a while. Dale
On 3/29/07, Travis Willard <travisw@wmpub.ca> wrote:
It's been brought up before, but I'd like to mention it - standardization of pre/post-install/remove messages in the .install file. Some kind of function that'll nicely format these messages, with the possibility to have them recorded to the pacman log as well, would be very useful.
There are two main ways to go about this. 1. standardize some system-wide message functions (which we want to do anyway) 2. Implement http://bugs.archlinux.org/task/1571 I think number 1 makes more sense in the long run, and still allows for smart display of messages (if previous version < x then display this message). Comments? -Dan
2007/3/29, Dan McGee <dpmcgee@gmail.com>:
On 3/29/07, Travis Willard <travisw@wmpub.ca> wrote:
It's been brought up before, but I'd like to mention it - standardization of pre/post-install/remove messages in the .install file. Some kind of function that'll nicely format these messages, with the possibility to have them recorded to the pacman log as well, would be very useful.
There are two main ways to go about this. 1. standardize some system-wide message functions (which we want to do anyway) 2. Implement http://bugs.archlinux.org/task/1571
I think number 1 makes more sense in the long run, and still allows for smart display of messages (if previous version < x then display this message). Comments?
Also please search through ML. There were suggestions and reminders few times. It will be useful to read them. -- Roman Kyrylych (Роман Кирилич)
On Thu, 29 Mar 2007 14:13:53 -0400 "Dan McGee" <dpmcgee@gmail.com> wrote:
There are two main ways to go about this. 1. standardize some system-wide message functions (which we want to do anyway)
+1 -- Travis
On 10:46 Wed 28 Mar , Aaron Griffin wrote:
Looks like it's time to move towards a 3.1 release. Dan and I both have a lot of items listed in our TODO lists, though most of them are code changes (doesn't affect the end user much).
So I'd like to open the floor up for ideas - what *functional* changes interest you all, as a user of pacman?
What about changing the /etc/pacman.d/* design? ( http://bbs.archlinux.org/viewtopic.php?pid=239378 ) Actually to change mirror you have to edit 5/6 files, a simpler solution would be appreciated. Cheers, -- Alessio 'mOLOk' Bolognino Arch Linux Trusted User http://www.archlinux.org
On 3/29/07, Alessio 'mOLOk' Bolognino <themolok.ml@gmail.com> wrote:
What about changing the /etc/pacman.d/* design? ( http://bbs.archlinux.org/viewtopic.php?pid=239378 ) Actually to change mirror you have to edit 5/6 files, a simpler solution would be appreciated.
http://bugs.archlinux.org/task/6389 :) We could do something along the lines of: Server = ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/archlinux/{current,extra,community}/os/i686/ The only complexity is how to handle the order of repos (i.e. testing and unstable vs current). I guess there could be a section where you specify order of repos... Order = testing, current, extra, community, unstable Just thinking out loud. Scott
2007/3/29, Scott Horowitz <stonecrest@gmail.com>:
Server = ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/archlinux/{current,extra,community}/os/i686/
BTW, what the hell that /os/ is always doing there (and what it means)? Why we need this useless subdir? Maybe just eliminate it sometime? (just thinking). -- Roman Kyrylych (Роман Кирилич)
On 3/29/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
BTW, what the hell that /os/ is always doing there (and what it means)? Why we need this useless subdir? Maybe just eliminate it sometime?
Right now it is to seperate the packages (os) from the install CD (isos). -Dan
2007/3/30, Dan McGee <dpmcgee@gmail.com>:
On 3/29/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
BTW, what the hell that /os/ is always doing there (and what it means)? Why we need this useless subdir? Maybe just eliminate it sometime?
Right now it is to seperate the packages (os) from the install CD (isos).
Really? But there are no ISOs in {current,extra,unstable,testing,community} - only os/{i686,x86_64} -- Roman Kyrylych (Роман Кирилич)
Roman Kyrylych wrote:
2007/3/30, Dan McGee <dpmcgee@gmail.com>:
On 3/29/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
BTW, what the hell that /os/ is always doing there (and what it means)? Why we need this useless subdir? Maybe just eliminate it sometime? Right now it is to seperate the packages (os) from the install CD (isos).
Really? But there are no ISOs in {current,extra,unstable,testing,community} - only os/{i686,x86_64}
I belive there's only current/iso, I don't think all mirrors mirror it check. (ftp://ftp.archlinux.org/current/iso). Andrew
2007/3/30, Andrew Fyfe <andrew@neptune-one.net>:
Roman Kyrylych wrote:
2007/3/30, Dan McGee <dpmcgee@gmail.com>:
On 3/29/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
BTW, what the hell that /os/ is always doing there (and what it means)? Why we need this useless subdir? Maybe just eliminate it sometime? Right now it is to seperate the packages (os) from the install CD (isos).
Really? But there are no ISOs in {current,extra,unstable,testing,community} - only os/{i686,x86_64}
I belive there's only current/iso, I don't think all mirrors mirror it check. (ftp://ftp.archlinux.org/current/iso).
Nevermind. Everything could be changed as we move to another repo structure. -- Roman Kyrylych (Роман Кирилич)
participants (9)
-
Aaron Griffin
-
Alessio 'mOLOk' Bolognino
-
Andrew Fyfe
-
Dale Blount
-
Dan McGee
-
Giovanni Scafora
-
Roman Kyrylych
-
Scott Horowitz
-
Travis Willard