Re: [aur-general] AUR Improvement Thread
Btw, there is a dude who's working on a git-backend-based AUR. pretty c^w very ambitious project, if you're interested in the topic, check him out. I was pretty sure he had a thread on the community contributions section of the forums, and i know myself and louipc have made posts in the thread, but I can't find it back :@ Dieter
Re: [aur-general] AUR Improvement Thread
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]. 2. User provided binaries (if case anyone wants to volunteer) (this should probably be carefully controlled) Hm, basically the problem with that is that people would need to trust every user uploading packages to the AUR just as they trust TUs or devs. There would be no easy way to check if a package contains malicious code. 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) If something has been obsoleted by something else, people can just mention that in the comments and/or send a mail to aur-general (as they always did). TUs will have a look at it then and remove it. That's so simple. 4. An official client Why? There is a huge number of clients that work well. I personally prefer to download AUR packages manually, build using makepkg(1) and use aurploader to upload stuff, some others prefer pacman wrappers, some others rather use aurbuild/makeaur. Why shouldn't we just let people decide how to do it? Isn't the do-it-yourself approach part of the Arch Philosophy? 5. LDAP support because LDAP makes everything so much better Hm. I'd be fine with that, but it isn't a must. The main problem is, that it's not easy to implement. We had that discussion before. But if you want to put much effort in integrating it everywhere in a clean way and also agree to maintain it, you'd get a yes from me :) [1] http://git.cryptocrack.de/?p=archlinux-packages.git;a=summary
Re: [aur-general] AUR Improvement Thread
On Wed, Nov 17, 2010 at 11:12 AM, Lukas Fleischer archli...@cryptocrack.dewrote: 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
Re: [aur-general] AUR Improvement Thread
Am Wed, 17 Nov 2010 19:30:02 +1300 schrieb Jonathan Conder jonno.conder+a...@gmail.com: 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
Re: [aur-general] AUR Improvement Thread
On Wed, 2010-11-17 at 11:17 +0100, Cédric Girard wrote: On Wed, Nov 17, 2010 at 11:12 AM, Lukas Fleischer archli...@cryptocrack.dewrote: 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.
Re: [aur-general] AUR Improvement Thread
2010/11/17 Kaiting Chen kaitocr...@gmail.com: 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. 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. 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. 4. An official client -1 No, but if point 1 is accomplished you will do your own client for handle it :) 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. -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
Re: [aur-general] AUR Improvement Thread
On Wed, 17 Nov 2010 12:01:48 -0200 Ángel Velásquez an...@archlinux.org wrote: 2010/11/17 Kaiting Chen kaitocr...@gmail.com: 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: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 signature.asc Description: PGP signature
Re: [aur-general] AUR Improvement Thread
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. 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. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [aur-general] AUR Improvement Thread
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=idupreeSeB=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
Re: [aur-general] AUR Improvement Thread
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=idupreeSeB=m , and have used ABS, but otherwise am not too familiar with how Arch's infrastructure is set up currently.) I'm going to toy around with building an LDAP backed AUR prototype. This looks like it might be really useful. Still doing research at this point. http://directory.apache.org/apacheds/1.5/versioning-and-snapshots.html -- Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [aur-general] AUR Improvement Thread
On Tue, Nov 16, 2010 at 8:17 PM, Kaiting Chen kaitocr...@gmail.com wrote: How can we make the AUR even better? I'll start: 1. Integrated distributed version control system I like this idea. At least the ability to track changes in PKGBUILDs would be fun. Similar to a wiki's revision history. 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. 2. User provided binaries (if case anyone wants to volunteer) (this should probably be carefully controlled) I don't really see how this fits in. The user can host their own repository already. I would rather KISS and leave the AUR source only. 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) Good idea. Better statistics could be gathered by simply adding a timestamp to votes db entries. Maybe pretty graphs too! 4. An official client The unofficial clients do nicely as it is and an official one is not necessary. Improving the official RPC would be nice though. 5. LDAP support because LDAP makes everything so much better LDAP makes everything so much more complicated! I avoid it whenever possible. -- -Justin
Re: [aur-general] AUR Improvement Thread
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/
Re: [aur-general] AUR Improvement Thread
On Wed, Nov 17, 2010 at 1:35 PM, Kaiting Chen kaitocr...@gmail.com wrote: ... I don't believe a centralized VCS is capable of this. Just so you know, a centralized VCS like svn or cvs can do the same thing. Just to reiterate, my personal preference is still git. I think it will be best because of its fast and light-weight nature. 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. 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=infoarg=$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. -- -Justin
Re: [aur-general] AUR Improvement Thread
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=infoarg=$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/
Re: [aur-general] AUR Improvement Thread
On Tue 16 Nov 2010 23:17 -0500, Kaiting Chen wrote: How can we make the AUR even better? I'll start: 1. Integrated distributed version control system 2. User provided binaries (if case anyone wants to volunteer) (this should probably be carefully controlled) 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) 4. An official client 5. LDAP support because LDAP makes everything so much better 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.
Re: [aur-general] AUR Improvement Thread
How does one commit to a local repository using SVN? I meant that you can do a 'svn update' or 'cvs update' to merge changes from the server into your working dir. -- -Justin
Re: [aur-general] AUR Improvement Thread
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/
Re: [aur-general] AUR Improvement Thread
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.
Re: [aur-general] AUR Improvement Thread
On 18 November 2010 09:48, Loui Chang louipc@gmail.com 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 kaitocr...@gmail.com 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.
[aur-general] AUR Improvement Thread
How can we make the AUR even better? I'll start: 1. Integrated distributed version control system 2. User provided binaries (if case anyone wants to volunteer) (this should probably be carefully controlled) 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) 4. An official client 5. LDAP support because LDAP makes everything so much better --Kaiting -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [aur-general] AUR Improvement Thread
On 17/11/10 17:17, Kaiting Chen wrote: How can we make the AUR even better? 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. Jonathan
Re: [aur-general] AUR Improvement Thread
On Tue, 2010-11-16 at 23:17 -0500, Kaiting Chen wrote: How can we make the AUR even better? I'll start: Won't comment on the others for now, but... 2. User provided binaries (if case anyone wants to volunteer) (this should probably be carefully controlled) No, if binaries are required it should be in [community]. It would also drastically increase bandwidth requirements (both up and down).
Re: [aur-general] AUR Improvement Thread
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/
Re: [aur-general] AUR Improvement Thread
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
Re: [aur-general] AUR Improvement Thread
On 17 November 2010 12:17, Kaiting Chen kaitocr...@gmail.com wrote: How can we make the AUR even better? I'll start: 1. Integrated distributed version control system 0 2. User provided binaries (if case anyone wants to volunteer) (this should probably be carefully controlled) -1 This should _never_ happen. One of the main problems is non-redistributable binaries, and we'll not be able to prevent that. The [community] repository serves this purpose. For anything else, including niche groups, separate projects can be set up. 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 4. An official client -1 You should know we do not allow this for a reason. This will never change. 5. LDAP support because LDAP makes everything so much better 0
