[arch-announce] Status Report 2007-11-20
roman.kyrylych at gmail.com
Fri Nov 23 08:16:30 EST 2007
2007/11/20, Aaron Griffin <aaronmgriffin at 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)
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?
> 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 (Роман Кирилич)
More information about the arch-announce