[arch-dev-public] Repo Distinctions

[Paul Mattal]

Roman Kyrylych wrote:
> 2007/10/17, Paul Mattal <paul at mattal.com>:
>> To Aaron's point about too many repos, I would say: There's no good
>> reason why you shouldn't be able to move packages easily from one repo
>> to another with one commandline-- that's what repoman is trying to
>> achieve. When repos are really that lightweight it stops being a big
>> deal if you have one more and starts being beneficial to have a more
>> detailed classification of your packages.
> 
> Repoman? Until it'll became a reality - it annoys me when it gets
> mentioned as a solution to anything. Sorry. :-/

I'm sorry that thinking forward towards a unified solution that 
reduces work for all of us annoys you.

Consider it without the name, then. Currently, using only pacman and 
not all of our other encumbering scaffolding, the following is 
sufficient to move a package from one repo to another:

move_package.sh:
#!/bin/bash
REPOHOME='/repos'
OLDREPO="$REPOHOME/$2"
NEWREPO="$REPOHOME/$3"

repo-remove $OLDREPO/$2.db.tar.gz $1
mv $OLDREPO/$1*.pkg.tar.gz $NEWREPO
repo-add $NEWREPO/$3.db.tar.gz $NEWREPO/$1*.pkg.tar.gz

I can now move packages between repos with:

$ move_package mypackage /path/to/{repo1,repo2}

When things are closer to that easy in our system, our work will be 
substantially less, the number of repositories will not matter, and 
our development hours will be more productive.

> What about all those users who will have to change their pacman.conf every time?

They change it once, if/when we decide to create the new repo. This 
is insubstantial work.

> The separation of extra gives no good results, zero, void, nil.

It hasn't been done yet, how can you be so sure? I'm not certain it 
WILL give good results, but I think it's likely, and as Aaron has 
pointed out, these things aren't so hard to try and aren't irreversible.

We've been trying the unified solution for many years now, why not 
try the separated solution?

>> Of course, if the argument is that devs should maintain packages in
>> [community] because the distinction between devs and TUs isn't
>> important, another solution would be to flatten things and have [core],
>> [mantle] and [extra] and let TUs and devs maintain packages in [extra].
> 
> Another thing would be to have community integrated in extra.
> This would also eliminate this issue that is annoying for users and
> TUs in current situation:
> 1) packages in community are built against core/extra:
> 2) testing is filled with db/openssl/gnome/anything-with-so-bump packages
> issue #1: users that use testing have to rebuild their community
> packages by themselves
> 3) packages get moved from testing to core/extra - at this time all
> needed packages are already rebuilt so nothing in core/extra gets
> broken
> issue #2: all community packages that depend on those moved packages
> are broken now. Users start complaining, TUs are in a rush for
> rebuilds.
> With either community-testing repo or community integrated into extra
> these issues disappear.

I believe that once the devs choose a design for the official repos 
we should mirror that design all the way down the line. For example, 
I plan to deploy a similar [mantle] / [crust] structure at my company.

>> But I still think it's worth separating the devs and the TUs.. this is
>> not to say we shouldn't poach regularly from the TU pool to devs, but
>> the TU post is a great way to get yourself trained to be a good dev.
>> Look at how many came through that way!
> 
> Separation of devs and TUs is not the same as separation of their
> packages into different repos just by factor of package ownership.

It is. Any TU can edit any package in community. Any dev can edit 
any package in extra. People edit my packages all the time.

When it comes time to trust, that is what matters.

> Seriously, what's wrong with main/mantle packages staying in extra and
> moving unimportant to community?
> What's the difference between packages maintained by developers and
> _trusted_ users? Community packages are not system-critical anyway.

I agree with you: I currently trust the devs and most of the 
community repo at about the same level. But I don't think that's ideal.

There SHOULD be a difference. We can find MORE people we trust LESS 
and those people should be training themselves as TUs. In fact, I 
have always encouraged the AUR to accomplish MORE and worry LESS 
about quality.. that's it's niche! If the packages were the same 
quality as the dev packages, then those TUs should become devs and 
take their packages with them.

- P