Aur is a friggin mess, I propose either a serious cleanup or a whipe.

Mr.Elendig · 2014-01-03 14:31:12

[oh@Alice][~/projects/clean-aur/aur-mirror]% echo * | wc -w
55989

[oh@Alice][~/projects/clean-aur/aur-mirror]% grep -lR --include PKGBUILD '_.*root' | wc -l
6759

[oh@Alice][~/projects/clean-aur/aur-mirror]% grep -RL --include PKGBUILD 'package()' | wc -l
19339

The numbers pretty much speaks for them self. There are thousands of packages using old PKGBUILD syntax in aur. 34.54% of all aur packages will stop working at pacman 4.2 release. If you also count packages that are plain broken, duplications, outdated and so on, I would not be supriced if the total number is close to 50%,

In my not so humble evil overlord of everything™<insert evil laughter and dramatic music here> opinion something drastic should be done. I propose that we set a time limit, if there have not been a major improvement in the overall quality of aur by that date, the current aur is moved as a backup and aur.archlinux.org is started again with a clean db. Active maintainers of packages can then easily reupload their packages (or perhaps a button on the backup page to move the package over).

Last edited by Mr.Elendig (2014-01-03 14:33:24)

maveric7911 · 2014-01-03 14:39:46

I support a wipe.

Allan · 2014-01-03 14:44:46

Mr.Elendig wrote:

not so humble evil overlord of everything™<insert evil laughter and dramatic music here>

Ehrm.... I'll let that slide this time!

What does that middle grep do? I am entirely missing something there.

Mr.Elendig · 2014-01-03 14:51:40

15:47:08 Desu ╡ allanbrokeit: checks for _gitroot etc in a horrible unreliable way

For those that wasn't present.

A bit of clarification:

backup of old aur would only stay up for eg 6 months

"Move to new aur" button would also transfer comments.

SanskritFritz · 2014-01-03 14:53:23

I'm afraid a wipe would really too drastic, as some valuable information would get lost, especially the comments on packages that worked once, and are just waiting for someone interested to step up and do some work. Would a backup still be accessible?
Maybe just reset the votes? That way the new votes would reflect more accurately what is used and is valuable today.

UPDATE: ah just read the 6 months deadline proposal.

Last edited by SanskritFritz (2014-01-03 14:54:22)

keenerd · 2014-01-03 15:01:17

A wipe is counterproductive. Adopt, fix and orphan.

This'll go over just like the python3 migration. The good maintainers will have already fixed their packages. The mediocre ones will do so in a flurry of excitement for their most commonly used packages during the first week. There will be a long tail of little used stuff that is gradually fixed, but by that time there will be hundreds of blog posts and a couple of wiki articles. With that much common knowledge, fixing pkgbuilds will be trivial for anyone including the large number of people who have never worked with pkgbuilds..

Edit: If you'd like to do something constructive, run "aurphan -a" click the links and take a look at the pkgbuilds. I've got 36 AUR ophans in use and while I don't care enough to adopt them, I do care enough to fix them. (Done! Of them 12 were broken. Erusfont, hellband, itpp, linm, metalua, nasm-git, perl-term-extendedcolor-tty, phctool-svn, rovclock, sane-pygtk, varkon, xsw.)

Edit edit: A sane proposal would be to loosen the 2-weeks notice and ML request to get a package disowned. If there are a lot of poorly-maintained packages, a quick way to fix important things would be to allow "Dredd-TU-ing" for a month or two. No package()? Instantly orphaned for someone else to pick up.

Last edited by keenerd (2014-01-03 18:17:24)

Trilby · 2014-01-03 15:06:45

Perhaps in addition to 'flag outdated' we could use a 'flag broken' (though I suppose there isn't much difference). Any flagged packages that aren't fixed in a timely manner can be removed.

Then take your grep commands and flag every result as outdated/broken (automated of course).

giddie · 2014-01-03 15:45:09

I think it would make a lot of sense to set up some sanity checking on AUR to check for common mistakes, old syntax, etc... and provide warnings for such packages.

maveric7911 · 2014-01-03 15:48:37

Add a broken button at the very least.

Nowaker · 2014-01-03 15:53:18

> either remove packages or remove packages, and have crap in AUR for a long time

I don't like neither of these approaches. I'd suggest to:

1. Create a wiki page with instructions on how to migrate packages to the new syntax
2. Write a simple script that will name all the AUR packages that won't work in new Pacman.
3. Mass-mail maintainers whose PKGBUILDs are identified by the script. Link to the wiki page and warn them the packages will be disowned if not fixed after X weeks.

Last edited by Nowaker (2014-01-03 15:54:22)

anatolik · 2014-01-03 15:54:55

I agree that wiping AUR is too disruptive.

And I support the idea of "easier orphaning" for the packages (it can be applied both for AUR and extra/community packages). There was a discussion in AUR maillist some time ago about automatic disown for broken/out-of-date packages https://mailman.archlinux.org/pipermail … 24511.html but it got nowhere. I hope that some useful steps will be done this time.

maveric7911 · 2014-01-03 16:06:04

Users have long needed the ability to flag a package of broken with some set of rules that the package is disowned or removed after being broken for a set period of time. This would at least begin to clean up a large amount of broken packages and clean up AUR as a whole.

ANOKNUSA · 2014-01-03 16:14:42

sanskritfritz wrote:

I'm afraid a wipe would really too drastic, as some valuable information would get lost, especially the comments on packages that worked once, and are just waiting for someone interested to step up and do some work.

I've lost count of the number of times I've read a comment on the AUR to the effect of "You need to change <setting x> to <value y>, or the package won't build," only to see the maintainer hasn't acted upon that change after a reasonable grace period. The package isn't marked as orphaned, and may not be flagged out-of-date, but it's effectively both. In my opinion, while an immediate wipe of everything may be a little too drastic, summarily doing away with anything that's been orphaned more than 6 months, resetting all AUR votes to zero, taking stock of things in [community] and making it clear that things will be done away with several months from now (and everything will need to be uploaded again) is reasonable. I'm not going to pretend to have any details in my head about how to proceed, but the sheer number of abandoned packages is staggering; start by just getting rid of them.

Also, in my totally non-authoritative opinion, there are certain packages in the AUR that the TUs might consider placing on some sort of probationary status, or even getting rid of, because they just don't seem (to me) to need the Arch Build System for any good reason, and so don't seem (to me) to belong in the AUR. I'm talking about toolkit and window manager themes, window manager plugins (think XMonad contrib) and variants (think DWM Sprinkles), Vim plugins and colorschemes, minor EMACS modes, Ruby gems, Python pip/easy_install packages, fonts---PKGBUILDs that are essentially overblown download-and-move-this-file scripts or calls to other operations (e.g. "gem install") rather than source build scripts, or which don't need to be installed to the root filesystem on single-user systems(and most of us probably have single-user systesms).

drcouzelis · 2014-01-03 16:19:44

ANOKNUSA wrote:

there are certain packages in the AUR that the TUs might consider placing on some sort of probationary status, or even getting rid of, because they just don't seem (to me) to need the Arch Build System for any good reason, and so don't seem (to me) to belong in the AUR.

I understand your point, but I see it the other way: It's exactly what the AUR is for. An Arch Linux user will think, "I want to use this software. I want it to be mananged by pacman so I can forget about it, so I'll create a simple PKGBUILD file for it. Maybe someone else will want to use this software, so I'll go ahead and dump it on the AUR." In my opinion, it's one of the things that makes Arch Linux and it's community so vibrant and flexible and simple.

My question: Has anything like this (wiping the AUR) ever been done in the history of Arch Linux?

Nowaker · 2014-01-03 16:35:13

Guys, stop thinking of wiping these packages. Stop thinking of numbers of packages that will need to be marked out-of-date. Stop thinking of the disaster that will come once new makepkg is released. Think of what can be done in order to **avoid** the disaster, to avoid wipe, and avoid tons of packages marked out of date. ;-)

Trilby · 2014-01-03 16:53:07

I'm not sure what resetting all votes to zero has to do with this. I have a few AUR packages, each with fairly meager vote tallies, but I'm still rather proud of them (tools I've written, not just packaged). While my ego would certainly survive it, why should my votes be reset to zero for no reason. I don't see what purpose this reset would serve.

A complete wipe with the ability to transfer over packages with comments and votes in tact seems extreme, but would serve a purpose and would be reasonable. Am I missing something that resetting the votes would accomplish?

ANOKNUSA · 2014-01-03 16:54:17

Nowaker wrote:

Guys, stop thinking of wiping these packages. Stop thinking of numbers of packages that will need to be marked out-of-date. Stop thinking of the disaster that will come once new makepkg is released. Think of what can be done in order to **avoid** the disaster, to avoid wipe, and avoid tons of packages marked out of date. ;-)

Absolutely---in the future. Prevention should definitely be part of this discussion, but the TUs still have a big ol' junkyard on their hands right now. And with regard to the upcoming pacman/makepkg update: How, exactly, does one avoid a problem by choosing to not anticipate it? This is something that will happen and, if I may be blunt, the folks who have reneged on their unwritten social contracts certainly aren't likely to take care of the problem. No doubt many of the PKGBUILDs with outdated syntax (or those that have been abandoned) were uploaded by people who aren't in the community anymore.

That said, I think Nowaker has a great point: Perhaps new policies regarding uploading and maintenance should be put in place before any destructive action is taken. How we implement some kind of screening and monitoring process without ballooning the number of people overseeing (and thus complicating) things... Hmmm...

clfarron4 · 2014-01-03 17:42:00

Nowaker wrote:

1. Create a wiki page with instructions on how to migrate packages to the new syntax
2. Write a simple script that will name all the AUR packages that won't work in new Pacman.
3. Mass-mail maintainers whose PKGBUILDs are identified by the script. Link to the wiki page and warn them the packages will be disowned if not fixed after X weeks.

I like these suggestions, especially 1) because I currently don't understand how to write a package with package().

Trilby · 2014-01-03 17:46:42

clfarron4 wrote:

I currently don't understand how to write a package with package().

I was going to ask if this was meant facetously (and I'm still not sure) - but I was surprised to find the wiki page does not actually include any information on this currently. The examples include package function, but the wiki doesn't cover it, and the man page only briefly mentions it as "optional."

[edit: from checking your current AUR entries, it looks like it was facetious, as 2 out of 3 use package() correctly, the third (awesome-cinnamon) could/should have the build function renamed to be the package function as nothing is actually built]

Last edited by Trilby (2014-01-03 17:51:30)

karol · 2014-01-03 18:01:06

maveric7911 wrote:

Add a broken button at the very least.

https://bugs.archlinux.org/task/18829

IIRC if you build a package w/o package() you get a warning.

clfarron4 · 2014-01-03 18:06:11

Trilby wrote:

clfarron4 wrote:
I currently don't understand how to write a package with package().
I was going to ask if this was meant facetously (and I'm still not sure) - but I was surprised to find the wiki page does not actually include any information on this currently. The examples include package function, but the wiki doesn't cover it, and the man page only briefly mentions it as "optional."
[edit: from checking your current AUR entries, it looks like it was facetious, as 2 out of 3 use package() correctly, the third (awesome-cinnamon) could/should have the build function renamed to be the package function as nothing is actually built]

The two packages (freetype2-ubuntu and lib32-freetype2-ubuntu) which have a package() function were already like that when I adopted them.

My awesome-cinnamon package is a fork of the awesome-gnome package, which never had a package() function to begin with and I'm trying to work out how to convert it over ¬¬

Last edited by clfarron4 (2014-01-03 18:06:44)

Scimmia · 2014-01-03 18:17:53

clfarron4 wrote:

Trilby wrote:
clfarron4 wrote:
I currently don't understand how to write a package with package().
I was going to ask if this was meant facetously (and I'm still not sure) - but I was surprised to find the wiki page does not actually include any information on this currently. The examples include package function, but the wiki doesn't cover it, and the man page only briefly mentions it as "optional."
[edit: from checking your current AUR entries, it looks like it was facetious, as 2 out of 3 use package() correctly, the third (awesome-cinnamon) could/should have the build function renamed to be the package function as nothing is actually built]
The two packages (freetype2-ubuntu and lib32-freetype2-ubuntu) which have a package() function were already like that when I adopted them.
My awesome-cinnamon package is a fork of the awesome-gnome package, which never had a package() function to begin with and I'm trying to work out how to convert it over ¬¬

The package function is where things are installed. The prepare() function is for making changes to the code, the build() function is for actually compiling the program, and the package() function is where you install the program to $pkgdir.

jasonwryan · 2014-01-03 18:29:51

Can we avoid turning this thread into a packaging primer? The wiki page can always be updated.

Back OT: I'm for a clean slate approach. It is the only sane way to remove all of the cruft.

Votes and comments for all migrated packages should be included.

dslink · 2014-01-03 20:39:42

Why not have two AUR servers, one is the current one and nothing is updated or changed on it, and the 2nd is the new one where maintainers will have to submit their packages to with the new PKGBUILD. Email all maintainers and tell them of this change. So over time the old AUR server will die out with no set time frame so comments and anything else is still online. And the new one can have flagging like maveric7911 was saying.

I know it sounds like a mess but at least you keep the data from the old server till what's needed is migrated to the new one.

karol · 2014-01-03 20:49:46

dslink, all the new features have to be developed first. AUR, like the rest of Arch Linux, has been created and is maintained by volunteers, so unless somebody shows up with the code, the features won't get implemented.

Arch Linux

#1 2014-01-03 14:31:12

Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#2 2014-01-03 14:39:46

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#3 2014-01-03 14:44:46

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#4 2014-01-03 14:51:40

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#5 2014-01-03 14:53:23

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#6 2014-01-03 15:01:17

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#7 2014-01-03 15:06:45

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#8 2014-01-03 15:45:09

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#9 2014-01-03 15:48:37

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#10 2014-01-03 15:53:18

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#11 2014-01-03 15:54:55

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#12 2014-01-03 16:06:04

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#13 2014-01-03 16:14:42

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#14 2014-01-03 16:19:44

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#15 2014-01-03 16:35:13

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#16 2014-01-03 16:53:07

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#17 2014-01-03 16:54:17

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#18 2014-01-03 17:42:00

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#19 2014-01-03 17:46:42

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#20 2014-01-03 18:01:06

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#21 2014-01-03 18:06:11

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#22 2014-01-03 18:17:53

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#23 2014-01-03 18:29:51

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#24 2014-01-03 20:39:42

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

#25 2014-01-03 20:49:46

Re: Aur is a friggin mess, I propose either a serious cleanup or a whipe.

Board footer