2007/11/6, Aaron Griffin <aaronmgriffin@gmail.com>:
ArchLinux Status Report, 2007-11-05
* The dividing line: extra and community
Another discussion that has gone by the wayside. I'll try to summarize here to see if we can a better idea.
The question: when does a package belong in extra?
We all agree that we need some sort of "rule" for this. There seems to be two big ideas on how to "answer" this question:
a) Split extra into "mantle" and "crust". Mantle contains packages "important to the distro" to be agreed upon by the developers, and crust contains anything else a developer wants to maintain.
b) The idea above remains the same, BUT extra is not split at all. The "mantle" packages go to extra, and "crust" packages go to community.
So, what do you guys think? Should we vote on these two to get things moving?
I agree with Eric. I like b) but without renaming. Or another way move Community into Extra and bring TUs as new packagers (we'll get enought people to create teams).
* DVD and Additional Package ISO Lists
Still not even a peep from people. This is the last time I'm going to include this item on the list. If we don't get any sort of activity or discussion on this, I am going to consider the matter closed.
The question: do we want to distribute additional DVDs/CDs full of packages? If so, how do we define what packages are on these things?
My time is very limited this month, but I will try to prepare such list (in fact, a list what we _don't_ want to distribute) next week.
* Unified chroot build tools
The new devtools release has pushed two of these tools out there: mkarchroot, for creating ArchLinux based chroots, and makechrootpkg, for running makepkg inside one of these chroots.
Currently, there are a few little bugs floating around, but feel free to report more.
The next step is to move to official usage here, so for you developers out there, PLEASE contact me if you have any problems - we should all be building packages in clean chroots to make sure hidden dependencies do not sneak into the packages, and I want to make these tools as easy to use as possible.
Besides fixing bugs (the most important of which is that makechrootpkg doesn't work) The very needed feature is the ability to create i686 chroots on x86_64. Could our x86_64 packagers help with this? I'm sure they have some scripts already.
* Getting rid of CVS
Last time we visted this, we had two potential implementations. The complexity here has to do with representing one package in many repos at the same time. _This_ is the problem that is solved by CVS tags that we need to redefine elsewhere.
Jason gave us an example svn implementation that used the following structure:
package-name/ PKGBUILD repos/ core/ testing/ blahblah/
Where each directory under repos/ is a new repository that contains a PKGBUILD and all supplemental files that are routinely "synced" with the master files (in the top level directory).
Dan gave us a git implementation that uses a similar structure, but uses git's "lightweight branches" in place of the repos/ directory. This also allows us to create rebuild branches and the like very easily. Here is a usage example:
git checkout -b foo_rebuild $EDITOR foo/PKGBUILD $EDITOR pkg1/PKGBUILD $EDITOR pkg2/PKGBUILD git commit -a
or
git checkout -b testing $EDITOR foobar/PKGBUILD git commit -a
The branch names above indicate a new repo, which contain only packages that are changed in the new branch.
So, I leave the floor open here - what do you guys think? Which is a better solution? I want to open this up to opinion and vote _real_ soon, as this is something we've talked about for so long it's becoming near mythical.
+1 for jason's SVN proposal. Looks very good to me. -- Roman Kyrylych (Роман Кирилич)