Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package

[Nirbheek Chauhan]

Hey,

On Sat, Aug 6, 2011 at 7:43 PM, Fabian Groffen <grobian@g.o> wrote:
> In this email, I step away from the current model that Gentoo uses for
> the gentoo-x86 repository.  Instead, I consider a repo-per-package
> model, as in use by e.g. Fedora [1] and Debian [2].
>
> In short, the repo-per-package model means that each package
> (my-cat/package) is a separate repository in some VCS.
> Instead of having a huge tree that will only grow forever (gx86),
> packages are just in their own repository.
>

I had mixed feelings while reading your email. The idea is certainly
very intriguing, but there's a few things that make it a no-go for me:

1. One of the big things I've been looking forward to with git is the
ability to do atomic commits across the tree. Addition of GNOME
releases, pkgmove changes across the tree, changing ebuild/eclass
behaviour, etc. without inconsistency or praying that my connection
doesn't get dropped in the middle of a hundred interrelated commits.

Without this feature, I think some arch teams and GNOME/KDE teams will
become sad.

2. The ability to do "feature" commits across the whole tree instead
of hundreds of tiny commits everywhere. This combined with the
ChangeLog generation will save a lot of time and space. This will
especially benefit arch teams, but I've felt the need for this
numerous times myself. Example: we moved to using .xz tarballs for
GNOME, and that touched a lot of ebuilds, and it was extremely
time-consuming to repeat echangelog && repoman commit per-package.

3. Adding packages from overlays via `cherry-pick` or `git am` will
become extremely tedious. If thin manifests are implemented, a series
of patches + a simple merge hook will be all you need to move
KDE/GNOME releases from the overlay to the tree. Without a single
tree, you need to go back to the current way of doing things.

4. We'll need to write extra tools to keep the user's cat/pkg list
up-to-date; adding and removing repositories as needed, etc. This is
added complexity for which we'll need volunteers (we've been facing a
manpower shortage already...)

5. The total size of the tree will increase a *lot* since all these
repositories will no longer share data. The current gentoo-x86 tree
stored in git without history takes only ~25MB because ebuilds are
extremely redundant. The space requirements will balloon once we need
to store 15,000 repositories. And arch teams will have to store *all*
of them, often on devices with very low space.

The per-package models looks very neat and tidy in some respects, but
the loss of a common git repository is too great, IMO.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team