Am Wed, 17 Nov 2010 19:30:02 +1300 schrieb Jonathan Conder :

I think it would be nice if people who click the Notify button get emailed when the package is updated, and not just when someone comments. Some maintainers don't say anything when they update.

You don't get an email when packages in the repos are updated, too. I'd suggest using an AUR and/or pacman wrapper like clyde, aurbuild, yaourt etc. and updating the system regularly. Heiko

No, if binaries are required it should be in [community]. It would also drastically increase bandwidth requirements (both up and down).

First, I'm still not actually sure what kind of resources Arch Linux has and if this would be a problem. Second, it would not if those binaries are hosted elsewhere. There's no way for a vested user to systematically say right now, "Hey I've compiled this package if anyone wants it." --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

On 17/11/10 17:02, Kaiting Chen wrote:

...

No, if binaries are required it should be in [community]. It would also drastically increase bandwidth requirements (both up and down).

First, I'm still not actually sure what kind of resources Arch Linux has and if this would be a problem. Second, it would not if those binaries are hosted elsewhere. There's no way for a vested user to systematically say right now, "Hey I've compiled this package if anyone wants it." --Kaiting.

Sure there is... and many people have made available repos: https://wiki.archlinux.org/index.php/Unofficial_User_Repositories

On 11/17/2010 12:13 PM, Dieter Plaetinck wrote:

...

5. LDAP support because LDAP makes everything so much better

no no no. please no. ldap is not pretty, and what problem are you trying to solve, anyway..

Dieter

i believe that one time registration process. -- Ionuț

On Wed, Nov 17, 2010 at 11:12 AM, Lukas Fleischer wrote:

On Tue, Nov 16, 2010 at 11:17:33PM -0500, Kaiting Chen wrote:

...

1. Integrated distributed version control system

Why would we need that? Keep it simple. People can setup their own repos if they want, just as I did [1].

[SKIP]

[1] http://git.cryptocrack.de/?p=archlinux-packages.git;a=summary

This works only as long as the maintainer stay the same. This is really different from an integrated, thus common, VCS. -- Cédric Girard

On Wed, Nov 17, 2010 at 2:59 PM, Heiko Baums wrote:

After the mass cleanup of [extra] ubuntulooks is now in AUR twice.

ubuntulooks (moved from [extra]) http://aur.archlinux.org/packages.php?ID=43548

gtk-engine-ubuntulooks http://aur.archlinux.org/packages.php?ID=11324

The latter has some patches. I don't know what they are doing. But I'd suggest removing one of these packages and call the other one gtk-engine-ubuntulooks as this is the recommended naming scheme for GTK engines.

Deleted ubuntulooks, thanks.

On Wed, 2010-11-17 at 11:17 +0100, Cédric Girard wrote:

On Wed, Nov 17, 2010 at 11:12 AM, Lukas Fleischer wrote:

...

On Tue, Nov 16, 2010 at 11:17:33PM -0500, Kaiting Chen wrote:

...

1. Integrated distributed version control system

Why would we need that? Keep it simple. People can setup their own repos if they want, just as I did [1].

[SKIP]

...

[1] http://git.cryptocrack.de/?p=archlinux-packages.git;a=summary

This works only as long as the maintainer stay the same. This is really different from an integrated, thus common, VCS.

Yes, as I understood the original post, the idea is that we have a history of changes in the PKGBUILD. Could be very useful.

On Wed, 17 Nov 2010 12:01:48 -0200 Ángel Velásquez wrote:

2010/11/17 Kaiting Chen :

...

How can we make the AUR even better? I'll start:

1. Integrated distributed version control system +1 but I think distributed is not necessary at all, but keeping the revisions of a PKGBUILD or the rest of the files will be nice.

I agree with Ángel a distributed VCS is not the correct choice here, I love git but for this a central one is the more useful. As I'm not fully into this either I thought a while about this and came to the conclusion, that a VCS might be to bloated in general. As I like the basic idea that it might be useful to keep the last x tarballs on the server just with growing "revisions" and if the count is full when a new one is submitted just the oldest one is removed. The naming scheme could be something like this pkgname.rev.tar.gz I don't think changing the upload part for that would be much work so if the idea is welcome I'll implement it (at least try to, don't work much with web stuff).

...

2. User provided binaries (if case anyone wants to volunteer) (this should probably be carefully controlled)

-1 ... if anyone wants to volunteer, they can apply to be a TU.

-1 I agree with Ángel, it's not that hard to become a TU, show that you're a nice guy, not slacking and trustworthy and you'll most probably become one.

...

3. Time-adjusted 'relevance' measure (votes are useful but suck at the same time; nobody cares if a packages was upvoted 9000+ times a million years ago, especially if it's already been obsoleted by something else)

0 No comments, maybe we should do one better statistic, number of downloads per day or something like.

-1 I think there is a lot of stuff out there which is useful but rarely gets new releases as the code fits it's specifications even after several years so for AUR I don't really see a point in that. Same for the comments for older packages that are used only by few users there are often old but still helpful comments.

...

4. An official client

-1 No, but if point 1 is accomplished you will do your own client for handle it :)

-1 We have pacman, for AUR there are scripts you may use when you are aware of the fact that this is not an official package of the distri- bution which you are installing right now, else some people might see a ports or emerge like util in this and we have the accusations if the stuff produces problems.

...

5. LDAP support because LDAP makes everything so much better

0 LDAP support just for AUR? I thought in LDAP to manage all our systems (forums, bbs, wiki, dev/tu backends) -but this requires soo manpower-, so I'd like to implement this, but not just for AUR .. and it will be good if these ideas goes to AUR2, because having LDAP + a VCS system will make a little bit painful the migration process, from the actual aur to the new aur.

0 I'm not familiar with LDAP except some minor information so I can't say to this proposal. Thanks for thinking about AUR, tough I don't like most of your proposals. ;-) -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4

On 11/17/10 14:32, Kaiting Chen wrote:

...

Thanks for thinking about AUR, tough I don't like most of your proposals. ;-)

That's fine. That's why I asked. I like most of my proposals but I've been around long enough to realize that what I like and what other people like are usually different.

I really would like to see some sort of integrated VCS system though. It's easy to tell what a new release in the official repositories contains by using the SVN interface. No such thing exists for the AUR.

+1. In fact, +2 because the AUR consists of relatively untrusted PKGBUILDs, so it should definitely be easier for AUR users to see the changes. If there's anything I can do to help implement this, I can spend some time on it. (I have a few AUR packages, http://aur.archlinux.org/packages.php?K=idupree&SeB=m , and have used ABS, but otherwise am not too familiar with how Arch's infrastructure is set up currently.)

Couple this with the fact that it's more trouble to build + install than just pacman -Syu, it's often difficult to determine whether or not one should update when an update is pushed to the AUR. --Kaiting.

AUR helpers help despite being unofficial. I use `clyde -Syu --aur` and it so far seemed to figure out everything except when packages needed rebuilding due to things like .so bumps or python3 upgrade etc. -Isaac

On Wed, 2010-11-17 at 15:53 -0500, Isaac Dupree wrote:

On 11/17/10 14:32, Kaiting Chen wrote:

...

I really would like to see some sort of integrated VCS system though. It's easy to tell what a new release in the official repositories contains by using the SVN interface. No such thing exists for the AUR.

+1.

In fact, +2 because the AUR consists of relatively untrusted PKGBUILDs, so it should definitely be easier for AUR users to see the changes.

This is the best reasoning I've seen so far for implementing a VCS.

Though a distributed VCS and not a centralized VCS is not really that necessary I use git mainly because it is fast, not because it is distributed. So I don't see why a distributed VCS would be any worse than a centralized one. The AUR is never going to be merging from another repo anyways... right? It would basically be read-only and might not even be publicly available as a repository so I don't see what difference it makes.

You could even go off on a tangent and have AUR maintainers be able to push to their own git repository on AUR ... muah.

A distributed VCS is nice because it allows someone to clone the repository and then commit to their local copy without necessarily pushing to a master repository. For example I download a PKGBUILD for package 'x'. I want to add support for LDAP, so I add --enable-ldap to ./configure. Now I commit my changes to my local clone. Then if the PKGBUILD on AUR changes, it is not necessary for me to repeat the process. I simply 'git pull' (s/git/whateverDVCSyouwant/) and the updates are merged for me. I don't believe a centralized VCS is capable of this. LDAP makes everything so much more complicated! I avoid it whenever

possible.

That is nonsense. With LDAP support one could for example query the details of a package "$pkgname" using the command: curl "ldap:// ldap.archlinux.org/ou=community,dc=archlinux,dc=org??one?(pkgname=$pkgname)" There's no way you can tell me that that's not awesome. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

Just so you know, a centralized VCS like svn or cvs can do the same thing.

How does one commit to a local repository using SVN? Sure I suppose if the LDAP spontaneously configures itself and

populates itself with data that is just great. I was talking about configuring LDAP, deploying LDAP, and populating it with data. That sucks. Ever type LDIF by hand? Fun.

That's not very awesome to me. You can do the same thing with AUR's RPC... without the fugly, esoteric LDAP syntax and without prior knowledge of how the directory is structured:

curl "http://aur.archlinux.org/rpc.php?type=info&arg=$pkgname"

I don't think it would be worth the effort of the programmer to convert the AUR to use LDAP as a storage backend to get features we already have. However, using LDAP for a centralized authentication/authorization server for the sites in the archlinux.org domain? That would be sweet.

Personally I think that LDAP is much easier to set up and populate than SQL. Also my LDAP query does not require an additional layer to translate HTTP -> SQL -> JSON. Though I suppose since this infrastructure is already in place this point is rather moot. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

I meant that you can do a 'svn update' or 'cvs update' to merge changes from the server into your working dir.

But you cannot commit to your local repository. Nor can you branch, tag, etc. Basically you can't do anything useful with a traditional VCS in a decentralized structure like the AUR. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

On 18 November 2010 09:48, Loui Chang wrote:

I'd almost say I'd like to see something like a Launchpad or Sourceforge for the AUR, with everything you need available via a more-or-less homogenous interface. But all features should be accessible via the command line as the core interface. It seems like everything out there is web based which bugs me for some reason.

+1 I feel the same for some reason. This I can say is worth dabbling into. On 18 November 2010 10:45, Kaiting Chen wrote:

...

I meant that you can do a 'svn update' or 'cvs update' to merge changes from the server into your working dir.

But you cannot commit to your local repository. Nor can you branch, tag, etc. Basically you can't do anything useful with a traditional VCS in a decentralized structure like the AUR. --Kaiting.

There are branches and tags in Subversion, though a little different (being it's all centralised). You can do everything useful if you put aside the concept of a local repository. But I guess that very same concept is what makes a decentralised VCS pretty versatile.