[arch-dev-public] Status Report: 2007-11-05

[Roman Kyrylych]

2007/11/6, Aaron Griffin <aaronmgriffin at 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 (Роман Кирилич)