[arch-announce] Status Report 2007-11-20

[Roman Kyrylych]

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