Roman Kyrylych wrote:
2007/10/17, Paul Mattal <paul@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