2007/11/20, Aaron Griffin <aaronmgriffin@gmail.com>:
ArchLinux Status Report, 2007-11-20
* The dividing line: extra and community
Ah, waning discussion is always fun. I've tried to revitalize this a few times, but it seems discussion feel short.
So here's a fun little ultimatum for ya:
Since no one seems to care about this topic anymore, if we don't get a vote, or at least continued discussion here, I'm going to have to make an "executive decision". That decision will be as follows:
* Packages in [extra] define us as a distro and should not include packages for personal use. If something is personal and/or only used by small amounts of people, it should go to community. Not only does this help us with our vision, it also helps out our mirrors (not all mirrors mirror the community repo). * People should inform everyone if they're putting a new package into extra, just in case someone has an issue with it, to prevent silly bloat from too many personal packages. If someone has a problem with a package going into extra, a simple vote should suffice (no need to discuss it to death)
+1 from me 'cause it's similar to my opinion.
* Unified chroot build tools
The chroot tools I've put in devtools have gotten little response. Jason has made some changes, and Roman has provided some patches, if I remember correctly.
Nope, I've only reported 3 issues. I've never used chroot and unionfs so I didn't know how to fix them. Jason already fixed them (I didn't try the latest devtools from git yet though).
* Getting rid of CVS
Yep, this is moving up the chain from long-term to short-term. Before the next status report (2 weeks from now) I want to at least begin this task.
In order to do this, we need to first make a decision on where we want to go. The root of the decision here is how we represent a given package being in multiple repos at one time.
* Jason has provided us with an svn solution, where sub-directories control the location of the package (i.e. package-name/repos/extra/PKGBUILD will place the package into extra) * Dan has provided us with a git solution that uses named branches to control the location (i.e. a branch named "testing" has changes to PKGBUILDs present only in the testing repo)
Both of the solutions above solve the issue. The real question is - what tool do YOU want to use?
+1 for Jason't SVN proposal. It's clear and simple. + it's seems much easier to get an ABS tree from it, browse it via ViewVC, etc.
* Architecture Independent Repos
More correct: Architecture Independent Packages They were intended to be placed in the same repos as i686/x86_64 packages, and in the same db.tar.gz They can be placed in $repo/os/any/ dir on FTP servers though (to save the space and traffic for mirrors) with $repo/os/{i686,x86_64}/$pkgname-$pkgver-$pkgrel-any.pkg.tar.gz being a symlink to ../any/$pkgname-$pkgver-$pkgrel-any.pkg.tar.gz (this is because packages should be in the same dir as .db.tar.gz for pacman to download them).
As stated last time, Roman sent us a patch for pacman 3.1 to incorporate the no-arch packages. This means that when the 3.1 release comes out, we should be ready to go here.
So here's your deadline: let's try and get support into our DB scripts before the pacman 3.1 release. Who's interested?
http://bugs.archlinux.org/task/8555
This one is a rather small change, is anyone interested in doing this? Thomas?
I'll try to get to this, but my time will be *very* limited until December 3nd. :-( -- Roman Kyrylych (Роман Кирилич)