ABS vs AUR

dtw · 2005-08-28 10:47:26

During the last TU meeting we broadly discussed whether updated PKGBUILDs for pkgs already in [current]/[extra] should or shouldn't be put in the AUR.

I personally am of the opinion that if the pkg can be easily built using ABS then there is no need for it to be included in the AUR. Clearly "easily" is a subjective and there are some special cases too:

· Real -devel versions are OK when a separate unstable branch exists, as for fvwm. This is NOT the same as development releases along the stable branch that could quite simply be covered with ABS.
· CVS pkgs - this seems to contradict 1) as CVS is just snapshots of a stable tree in 90% of cases. However, CVS based PKGBUILDs often require an entirely new approach to the PKGBUILD and cannot easily be updated from ABS. Futher, in most cases, once a CVS PKGBUILD has been added to the AUR it doesn't need to be updated as regularly as other PKGBUILDs, the user simply uses the PKGBUILD to checkout and build when they see fit.

My final concern is a broad "deskilling" Arch users. If we are spoon-feeding them customized PKGBUILDs for stock pkgs rather than encouraging them to use ABS then that means a general downward trend in skill IMO.

In fact, I talked to someone today who submits pkgs to the AUR but has never heard of ABS.

Essential, the AUR should not replace ABS, which is a hugely powerful and useful tool and helps to make Arch what it is. But many people do not realize that the AUR is in fact and extention of the ABS philisophy.

So, discuss amongst yourselves. We the TUs want to know what you think. My findings so far are going to get written up for the newsletter at some point.

Lastly I would like to point out that no-one is "in trouble" and no-one is doing anything "bad" per se, but there is a gap in guidelines and knowledge somewhere and I would like to fill it.

I think the upshot may be a drive to repromote ABS over the AUR

Cam · 2005-08-28 23:13:57

Ha, ABS is cool. Why write a pkgbuild for a new version of an app when an old one exists just waiting for you

sullivanva · 2005-08-29 04:35:35

dibblethewrecker wrote:

So, discuss amongst yourselves.

I'm feeling a little verklempt. My back is aching, and now you want me to learn something new?

I got the ABS installed, and I build all my packages in /var/abs/local for goodness sake.

I'm a polite person. Which is to say, "Bring it on!"

"Come and get one in the yarbles, if ya have any yarbles, ya eunuch jelly thou!"

--Malcolm McDowell in A Clockwork Orange

Snowman · 2005-08-29 05:21:05

dibblethewrecker wrote:

During the last TU meeting we broadly discussed whether updated PKGBUILDs for pkgs already in [current]/[extra] should or shouldn't be put in the AUR.

Any chance of getting a log of the last meeting?

dibblethewrecker wrote:

I personally am of the opinion that if the pkg can be easily built using ABS then there is no need for it to be included in the AUR. Clearly "easily" is a subjective and there are some special cases too:

I would define easy as "only changing the pkgver is sufficient to build the new version of the package". Also, if a package of the official repos is broken, users should use the bugtracker and not post a fixed PKGBUILD in the AUR.

dibblethewrecker wrote:

· Real -devel versions are OK when a separate unstable branch exists, as for fvwm. This is NOT the same as development releases along the stable branch that could quite simply be covered with ABS.
· CVS pkgs - this seems to contradict 1) as CVS is just snapshots of a stable tree in 90% of cases. However, CVS based PKGBUILDs often require an entirely new approach to the PKGBUILD and cannot easily be updated from ABS. Futher, in most cases, once a CVS PKGBUILD has been added to the AUR it doesn't need to be updated as regularly as other PKGBUILDs, the user simply uses the PKGBUILD to checkout and build when they see fit.
My final concern is a broad "deskilling" Arch users. If we are spoon-feeding them customized PKGBUILDs for stock pkgs rather than encouraging them to use ABS then that means a general downward trend in skill IMO.
In fact, I talked to someone today who submits pkgs to the AUR but has never heard of ABS.
Essential, the AUR should not replace ABS, which is a hugely powerful and useful tool and helps to make Arch what it is. But many people do not realize that the AUR is in fact and extention of the ABS philisophy.

Maybe the above two rules (or a modified version depending on user feedback) as well as a mention (or short introduction?) to ABS should be put in the AUR Guidelines. New AUR users will then be aware of ABS.

phrakture · 2005-08-29 07:07:04

I can see xentac beating his head against a wall - this is exactly what srcpac was made for.... if you want the official version of package-foo, but with "--option-bar" disabled, you add a real quick line to srcpac and build it - you don't even have to touch the PKGBUILD.

Karma XXL · 2005-08-29 07:33:39

Snowman wrote:

Any chance of getting a log of the last meeting?

I second that. Could someone please share the log, like the earlier meetings'?

dtw · 2005-08-29 10:56:15

Errr, it was not much of a meeting...more of an informal chat...you can see the log if you want but...it's not much to see.

tomk · 2005-08-29 14:19:35

I'd agree with those rules overall. I have to say I find it annoying to see PKGBUILDS in the AUR for existing repo packages, and the idea of making AUR submissions without knowing about ABS just leaves me speechless.

louipc · 2007-03-02 04:34:16

I'd agree with that for the most part except where those current/extra packages have been flagged out-of-date for a long time meaning the maintainer is either lazy or doesn't check his/her email. In that case it would just be an updated package, not really a customized build.

extra/gcin is out-of-date BTW.

phrakture · 2007-03-02 05:52:03

louipc wrote:

except where those current/extra packages have been flagged out-of-date for a long time meaning the maintainer is either lazy or doesn't check his/her email

You're winning no friends pulling crap like this. We all have busy lives. Don't make stupid assumptions until you know what you're talking about. I'd go on and respond to your actual content, but, quite frankly, I can't get past the glaring idiocy.

cromo · 2007-03-02 13:06:42

I personally would rather say these two should be integrated. It seems a bit unnatural to split the PKGBUILDs between two different repositories (ABS, AUR) and use separate tools for these two (I mean the 'abs' and 'yaourt' for example). What we should see is one repository, one tool and an effective emphasization of the stable/unstable (supported/unspported) state of the PKGBUILD. I also think that pacman should live next to some kind of pacsrc tool that would work pretty much the same except for building PKGBUILDs (from unified ABS/AUR repo) instead of downloading binary packages. I know that similar tools exists (e.g. yaourt), but I meant an offically supported tool here. I alsko know this has been discussed to death, but eventually this issue needs a solution.

lucke · 2007-03-02 13:42:30

Maybe, instead of wondering about dealing with the effects of outdated packages in the repos, there could be something done to minimize the number and time-of-being-out-of-date of them?

I'm actually not overly familiar with the way devteam works. Perhaps stepping in by another person, just to bump a pkgver in a PKGBUILD (obviously when it is that trivial) and rebuild, when certain circumstances are met (like dev responsible hasn't been active for some time/is officially on holiday/very busy), would be in order?

Personally, I see dorphell is a constant culprit when it comes to outdated packages. Of all the packages (easytag, nvclock, moc, xine-lib) I've currently newer locally than are available remotely, all are dorphell's and have been out of date for quite long. It proves that situation isn't bad, but also clearly shows that dorphell could use some assistance.

As for other packages, maybe there could be some additional field with explanation added to packages in websearch? If update is nontrivial or problematic (as with clamav), dev could indicate there that he is aware of the problem, but something is stopping him from the update. Any other mechanism is good, as long as it allows to distinguish "abandoned" packages from the problematic ones. Additionally, I think there are plenty of people who would be eager to help the devs with problematic packages (be it testing or seeking solutions), if they only knew the problems are there.

If I'm at it, I wonder how do the devs deal with packages with no official maintainer. Whose responsibility is to update them?

Last edited by lucke (2007-03-02 13:42:58)

skymt · 2007-03-02 14:46:09

phrakture wrote:

louipc wrote:
except where those current/extra packages have been flagged out-of-date for a long time meaning the maintainer is either lazy or doesn't check his/her email
You're winning no friends pulling crap like this. We all have busy lives. Don't make stupid assumptions until you know what you're talking about. I'd go on and respond to your actual content, but, quite frankly, I can't get past the glaring idiocy.

I think what louipc meant to say is that adopting a package is a commitment. If the maintainer is too busy to keep the package up-to-date (perfectly understandable), the right thing to do would be to let someone else (probably someone who uses it) maintain it.

Last edited by skymt (2007-03-02 14:46:56)

phrakture · 2007-03-02 16:07:41

skymt wrote:

I think what louipc meant to say is that adopting a package is a commitment. If the maintainer is too busy to keep the package up-to-date (perfectly understandable), the right thing to do would be to let someone else (probably someone who uses it) maintain it.

I'd agree with that, but I don't read between the lines. My original sentiment still stands.

That said, there's a large amount of packages and it's hard to keep track of them all. I'll try to prod the dev team and see if we can figure this out, as I've seen this complaint a few times as of late.

toofishes · 2007-03-02 16:57:05

cromo wrote:

I personally would rather say these two should be integrated. It seems a bit unnatural to split the PKGBUILDs between two different repositories (ABS, AUR) and use separate tools for these two (I mean the 'abs' and 'yaourt' for example). What we should see is one repository, one tool and an effective emphasization of the stable/unstable (supported/unspported) state of the PKGBUILD. I also think that pacman should live next to some kind of pacsrc tool that would work pretty much the same except for building PKGBUILDs (from unified ABS/AUR repo) instead of downloading binary packages. I know that similar tools exists (e.g. yaourt), but I meant an offically supported tool here. I alsko know this has been discussed to death, but eventually this issue needs a solution.

extra/srcpac 0.4.1-1
    The pacman from-source wrapper

phrakture had already mentioned it too, but I think this is what you want.

louipc · 2007-03-03 15:49:44

phrakture wrote:

louipc wrote:
except where those current/extra packages have been flagged out-of-date for a long time meaning the maintainer is either lazy or doesn't check his/her email
You're winning no friends pulling crap like this. We all have busy lives. Don't make stupid assumptions until you know what you're talking about. I'd go on and respond to your actual content, but, quite frankly, I can't get past the glaring idiocy.

Sorry. I assumed packages in current and extra would be ones that are given special attention to be maintained. I wouldn't have said the same thing about unstable, community, etc..
Yeah sure I have a busy life too; sometimes I put back things that I really should take care of. Being busy doesn't mean I'm not being negligent, or procrastinating. I didn't mean to insult.

Last edited by louipc (2007-03-03 17:47:46)

dtw · 2007-03-03 19:07:15

I think more floating devs might work to be honest. I have said it before.

Devs often get recruited and bring certain pkgs with them. Sometimes in from [community]. Maybe it would be nice for a few people to get a shot at simply doing pkgver bumps and simple one-line bug fixes.

I posted my nfs pkg patch months ago, it's a simple change, harmless to those who don't need it and it works perfectly but Judd is basically too busy to merge it. This is a silly situation and if there were more devs, maybe even registered pkg monkeys to float about and fix ANY pkg, as necessary, then a whole lot of simple shit would get fixed.

I'm sure there is a toe treading issue in there somewhere but at some point the good of the distro has got to come above personal feelings/disgruntlement. I'm aware that there is some concern of quality over quantity when it comes to devs but I really do think that, at some point, critical mass will be reached. I think the time that any person can contribute to such a project as Arch works on a bath tub curve, with mid-life being the most difficult period, and we sure ain't getting any younger round here.

I'm also curious about how the dev group operate as the driving force of the distro. We who do not have access to what the devs talk about on the dev list can only guess what is said but I'm sure there are certain discussions on "the way forward". I don't see any reason why a person that maintains pkgs in [current]/[extra] should necessarily become part of that steering group and maybe it is time to consider a tier between the TUs and dev group to fill the day-to-day gaps.

cromo · 2007-03-03 23:23:08

toofishes wrote:

phrakture had already mentioned it too, but I think this is what you want.

Errr you misunderstood my point I know about the tools but i'd rather see them working with unified aur/abs repository.

lucke · 2007-03-04 00:43:51

I want to be a pkg monkey!

japetto · 2007-03-19 13:26:02

I posted my nfs pkg patch months ago, it's a simple change, harmless to those who don't need it and it works perfectly but Judd is basically too busy to merge it. This is a silly situation and if there were more devs, maybe even registered pkg monkeys to float about and fix ANY pkg, as necessary, then a whole lot of simple shit would get fixed.

On an off note, I used that patch and it simplified things for me greatly. Thanks for the patch and uh back to topic

ihavenoname · 2007-04-01 20:49:46

I agree with dtw. A few extra people to help out would be a good thing. It would help the core dev team focus on the more important issues without having to worry about all the packages getting out of date. This will become more of an issue as the repo size grows. There has to be a system of control however to ensure that things don't get out of hand. Maybe there needs to be a certain ratio of "monkeys" to packages that limits the strain. With the most essential packages being relegated to the most senior dev teams. For example, the kernel should really remain under the control of the core team. But smaller applications are not essentially to the functioning of the system as a whole do not necessarily need to be looked after by the core team.

I think we need to look at Debian to seem what merits/mistakes their system has, as well as other distros and try to take the best approach possible. (For example, it seems debian's control is too diluted at this point and needs a slightly more centralized version of control. One the other hand Ubuntu might be too centralized in some aspects. etc.)

STiAT · 2007-05-14 15:23:01

I am a monkey, but pkg? .

Finally, a lot of you agree, and discuss in the public that more arch staff is needed. That's fine, since a lot of people did not even know for a long time how busy you all are, and that it's nearly impossible to keep the packages up to date.

Anyway, get your thoughts clear, and choose interested people for this tasks. Quite everyone who knows how to handle shell and how a PKGBUILD should look could do this task of rebuilding packages, applying patches and maybe doing a little bit of other work, so you can concentrate on the real important and hard things (maybe flagged by those pkgmonkeys that they experienced harder problems).

The build systems: I see AUR as an "addition" to ABS. I must aggree that sometimes packages appear twice, i also had this happening when i was about to build around 30 packages, it happened that two of them were in abs. I finally realized it and removed them (dani reported one though). The problem there was that the package was simply differently named, and i did not realize that when i searched.

As always, things like this can happen, as a corrupted gzip package was on the mirrors once. Of course i aggree with you that people should take a closer look, but sometimes people just don't care about abs.
Personally - something with an interface makes it by far sexier. Also, i can't update abs at work. Would need a SVN server with webdav instead of cvs...

a1ex · 2008-04-02 05:34:03

I think its a problem of documentation. When I started with Arch I was hardly aware of abs. I'm using it today to modify or update some single PKGBUILDs but still havent heard of srcpac as of now. Maybe someone should write a guide on how to manage packages the intended way using all those tools with given examples.

LTSmash · 2008-05-17 21:38:24

Maybe AUR is just better documented than ABS...

iphitus · 2008-05-18 09:35:40

AUR vs ABS?

ABS wins! 5 scrabble points > 3 scrabble points

Arch Linux

#1 2005-08-28 10:47:26

ABS vs AUR

#2 2005-08-28 23:13:57

Re: ABS vs AUR

#3 2005-08-29 04:35:35

Re: ABS vs AUR

#4 2005-08-29 05:21:05

Re: ABS vs AUR

#5 2005-08-29 07:07:04

Re: ABS vs AUR

#6 2005-08-29 07:33:39

Re: ABS vs AUR

#7 2005-08-29 10:56:15

Re: ABS vs AUR

#8 2005-08-29 14:19:35

Re: ABS vs AUR

#9 2007-03-02 04:34:16

Re: ABS vs AUR

#10 2007-03-02 05:52:03

Re: ABS vs AUR

#11 2007-03-02 13:06:42

Re: ABS vs AUR

#12 2007-03-02 13:42:30

Re: ABS vs AUR

#13 2007-03-02 14:46:09

Re: ABS vs AUR

#14 2007-03-02 16:07:41

Re: ABS vs AUR

#15 2007-03-02 16:57:05

Re: ABS vs AUR

#16 2007-03-03 15:49:44

Re: ABS vs AUR

#17 2007-03-03 19:07:15

Re: ABS vs AUR

#18 2007-03-03 23:23:08

Re: ABS vs AUR

#19 2007-03-04 00:43:51

Re: ABS vs AUR

#20 2007-03-19 13:26:02

Re: ABS vs AUR

#21 2007-04-01 20:49:46

Re: ABS vs AUR

#22 2007-05-14 15:23:01

Re: ABS vs AUR

#23 2008-04-02 05:34:03

Re: ABS vs AUR

#24 2008-05-17 21:38:24

Re: ABS vs AUR

#25 2008-05-18 09:35:40

Re: ABS vs AUR

Board footer