Comments and some of my own stuff here. On 3/28/07, Andrew Fyfe 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

2007/3/28, Dan McGee :

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

...

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

2007/3/29, Dan McGee :

On 3/29/07, Travis Willard 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 (Роман Кирилич)

2007/3/29, Scott Horowitz :

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 (Роман Кирилич)

2007/3/30, Dan McGee :

On 3/29/07, Roman Kyrylych 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 (Роман Кирилич)

2007/3/30, Andrew Fyfe :

Roman Kyrylych wrote:

...

2007/3/30, Dan McGee :

...

On 3/29/07, Roman Kyrylych 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 (Роман Кирилич)