Re: [aur-general] Discussion period - Moving [community] to use same system as main repos
-----Original Message-----
Date: Fri, 09 Jan 2009 18:33:38 +0100 Subject: [aur-general] Discussion period - Moving [community] to use same system as main repos From: Allan McRae To: "Discussion about the Arch User Repository (AUR)"
Hi all,
To get this moving along, I would like to start the official discussion period. Standard rules, 5 days discussion, 7 days voting, 75% quorum. If discussion raises some points which really need to be addressed before a vote then it can be delayed.
Abhishek has mad a good summary with some additions by Loui at http://wiki.archlinux.org/index.php/Community_move_to_devtools .
Hello, I have been thinking about the detriments and benefits and her are my comments:
Detriments * It might affect the autonomy of Trusted Users.
This is a big point to me. One very important reason for me to use Arch Linux is the existence of a great community contributing packages and the possibility to get them to a semi official repo in an easy way.
*and this is a big change from the way we've been used to.
That is true but only concerns our, the TU's, comforts. So it is not that important, we are all able to learn.
* The effort to make the transition happen is not trivial.
I cannot imagine how complicated it would be.
*You'd lose votes for community packages.
Well, we did just have a proposal in which one of the prerequisites for putting a package to [community] was the number of votes. Votes are also an indicator that users want a package to be kept in [community]. Strengthen the rule of votes in one proposal and weaken it in the next one is not an consistent attitude.
* You'd lose package comments and notifications.
* Combining community packages with official packages will contribute a
This is also important to me. It is much easier to write a comment than to use a bugtracker for users. performance hit for all repos when dealing with >build files. Cannot comment because i do not get the point. <* There'll be fewer tools to support, since Trusted Users would then use the same tools as Arch developers, but with reduced permissions (only permission to write to the [community] repository) This is a very minor point to me. I do not know how hard it is to maintain these tools, but is only a concern of very few people. <* It'd be much easier to create and maintain a [community-testing] repository (or even the [testing] repository, if it's possible to cleanly separate the relevant permissions). A testing repository for [community] would be a great help in doing rebuilds. I do not see that this is very important. I did not need such a repo up to now and most probably wont use it. <* It'll be easier to migrate from being a Trusted User to a developer, since all the repositories would be using the same infrastructure. A simple permissions change, and they could be uploading packages to [core] or [extra]. I have absolutely no ambitions to becaome a developer. This point leads back to the first point under the "Detriments" section. If a TU wants to become a developer, he or she has do move his or her packages once, or even leave them in community, so the benefits are small. IMHO this point has to be moved to the "Detriments" section. <* [community] would naturally become more decoupled from the AUR. Packages in [community] would become visible on the main Arch website, giving greater visibility to [community]. Also the search function on the website would then be able to search across all the repositories. This is clearly a detriment to me. < * The AUR code becomes greatly simplified, making code refactoring or rewrites easier. < * The server daemon (tupkgupdate.py) for adding packages to [community] and other associated cruft which has been lying around for ages can be got rid of. Cannot comment So in my opinion at now the benefits are small and the goals are not mine. A clear -1 from me. Regards Stefan
Just addressing a handful. On Fri, Jan 9, 2009 at 2:04 PM, stefan-husmann@t-online.de <stefan-husmann@t-online.de> wrote:
*You'd lose votes for community packages.
Well, we did just have a proposal in which one of the prerequisites for putting a package to [community] was the number of votes. Votes are also an indicator that users want a package to be kept in [community]. Strengthen the rule of votes in one proposal and weaken it in the next one is not an consistent attitude.
I don't think this one is about "political consistency" - this proposal is more about technical superiority. It's a technically better move, so the proposal says "ok, screw the politics"
<* There'll be fewer tools to support, since Trusted Users would then use the same tools as Arch developers, but with reduced permissions (only permission to write to the [community] repository)
This is a very minor point to me. I do not know how hard it is to maintain these tools, but is only a concern of very few people.
This is a very very BIG point. I remember back when pacman added in new sizes, so that one could easilly see "total unpacked size" from new packages. The community repo did not have these sizes added in, so the numbers were treated as 0. You'd get things like: Total Download Size: 300MB Total Installed Size: 7MB And people would yell and complain and file bug reports. This *only* happened because we have different tools managing the community repo as compared to the official repos (which stay up-to-date with regard to pacman changes, as much as possible)
<* It'll be easier to migrate from being a Trusted User to a developer, since all the repositories would be using the same infrastructure. A simple permissions change, and they could be uploading packages to [core] or [extra].
I have absolutely no ambitions to becaome a developer. This point leads back to the first point under the "Detriments" section. If a TU wants to become a developer, he or she has do move his or her packages once, or even leave them in community, so the benefits are small. IMHO this point has to be moved to the "Detriments" section.
I think the point here was more about the actual _people_, not the packages. If JoeSchmoe becomes a developer, he has no extra learning to do and can begin work much easier.
<* [community] would naturally become more decoupled from the AUR. Packages in [community] would become visible on the main Arch website, giving greater visibility to [community]. Also the search function on the website would then be able to search across all the repositories.
This is clearly a detriment to me.
Wait... can you explain how this is a detriment?
< * The AUR code becomes greatly simplified, making code refactoring or rewrites easier.
< * The server daemon (tupkgupdate.py) for adding packages to [community] and other associated cruft which has been lying around for ages can be got rid of.
Cannot comment
This is one of the most important points here. The backend managing the community repo is, quite frankly, painful. It causes us way more harm than the official repos ever had. Getting rid of this is the sole reason I think this entire thing is work it. I think we're mixing up a lot of issues here. Arch has always striven for _technical_ superiority. Recently, we've had way too much talk of politics and autonomy and all this other cruft and bureaucracy. The simple fact is: this is a technically superior choice. Just my 17 cents.
*You'd lose votes for community packages. * You'd lose package comments and notifications.
Ok, those may not be completely true. My fault. I'll edit the wiki. We we can still keep community packages in the AUR interface, but I was assuming that the proposal was to ditch them. It will just take a bit of patching to keep them.
This is also important to me. It is much easier to write a comment than to use a bugtracker for users.
* Combining community packages with official packages will contribute a performance hit for all repos when dealing with >build files.
Cannot comment because i do not get the point.
Well, the way the arch SVN repo for build files is organised is by packages, not by repos. That means all community packages will be thrown in together with core, extra, and testing packages. To get a checkout of community you would have to scan every package directory to see if it's actually in community. I'm not sure if it's possible via standard subversion tools either. Have a browse through http://repos.archlinux.org/viewvc.cgi/ to get a better idea. I'm not totally sure what I think of the proposal, because it isn't really detailed enough. Depending on the implementation I may be for it or against it.
On Fri, Jan 9, 2009 at 2:35 PM, Loui Chang <louipc.ist@gmail.com> wrote:
*You'd lose votes for community packages. * You'd lose package comments and notifications.
Ok, those may not be completely true. My fault. I'll edit the wiki. We we can still keep community packages in the AUR interface, but I was assuming that the proposal was to ditch them. It will just take a bit of patching to keep them.
This is also important to me. It is much easier to write a comment than to use a bugtracker for users.
* Combining community packages with official packages will contribute a performance hit for all repos when dealing with >build files.
Cannot comment because i do not get the point.
Well, the way the arch SVN repo for build files is organised is by packages, not by repos. That means all community packages will be thrown in together with core, extra, and testing packages.
To get a checkout of community you would have to scan every package directory to see if it's actually in community. I'm not sure if it's possible via standard subversion tools either.
I'm not sure what you mean here. The official repos did away with the "scan all packages" thing a while back. There's no need to regenerate an entire list of all packages, assuming we maintain state properly. Every operation is an add or a remove. We simply use SVN to ensure that the package belongs in that repo. So when I say "ok, let's add openssh to core", the tools make sure we have a PKGBUILD listed in "openssh/repos/core-i686". If it's there, it makes sure the versions are the same. If all is well, the package is added to the DB. The web interface uses a DB that is based on pacman's DB. There is a cron job that grabs the current "core.db.tar.gz" that pacman uses, and simply dumps it into a mysql DB for use by the front end.
On Fri, Jan 09, 2009 at 02:52:18PM -0600, Aaron Griffin wrote:
Well, the way the arch SVN repo for build files is organised is by packages, not by repos. That means all community packages will be thrown in together with core, extra, and testing packages.
To get a checkout of community you would have to scan every package directory to see if it's actually in community. I'm not sure if it's possible via standard subversion tools either.
I'm not sure what you mean here. The official repos did away with the "scan all packages" thing a while back. There's no need to regenerate an entire list of all packages, assuming we maintain state properly. Every operation is an add or a remove. We simply use SVN to ensure that the package belongs in that repo.
What I mean is that it doesn't seem like someone could easily checkout the build files for just community packages. In that case how do you set up permissions properly if trunk build files don't belong to any particular repo? Seems TUs would have access to everything no?
On Fri, Jan 9, 2009 at 3:09 PM, Loui Chang <louipc.ist@gmail.com> wrote:
On Fri, Jan 09, 2009 at 02:52:18PM -0600, Aaron Griffin wrote:
Well, the way the arch SVN repo for build files is organised is by packages, not by repos. That means all community packages will be thrown in together with core, extra, and testing packages.
To get a checkout of community you would have to scan every package directory to see if it's actually in community. I'm not sure if it's possible via standard subversion tools either.
I'm not sure what you mean here. The official repos did away with the "scan all packages" thing a while back. There's no need to regenerate an entire list of all packages, assuming we maintain state properly. Every operation is an add or a remove. We simply use SVN to ensure that the package belongs in that repo.
What I mean is that it doesn't seem like someone could easily checkout the build files for just community packages.
In that case how do you set up permissions properly if trunk build files don't belong to any particular repo? Seems TUs would have access to everything no?
In the SVN repo, yes. We currently handle permissions in a rather open way. The svn repo is entirely open to anyone to just do what they want. This comes in very handy when someone wants to do things like update licenses or fix someone else's package. It's the actual package uploading that is permission restricted. Only a subset of the developers have access to the core repo. While anyone can change build files for packages in core, not everyone can actually update the packages themselves. In code, if I wanted to checkout all of the community build files, I would do something akin to (quick pseudo code): mkdir community for pkg in community.db.tar.gz: svn co svn-packages/$pkg/trunk community/$pkg or something of the sort. It'd be slow over ssh, so I would make sure to use a ControlMaster socket for that... but locally it should be fairly quick.
participants (3)
-
Aaron Griffin
-
Loui Chang
-
stefan-husmann＠t-online.de