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).

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

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.

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

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.

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

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

> 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 syntax2. 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.

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

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.

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

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.

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

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).

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

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?

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

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. ;-)

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

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?

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

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...

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

Nowaker wrote:

1. Create a wiki page with instructions on how to migrate packages to the new syntax2. 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().

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

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]

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

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 ¬¬

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

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.

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

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.

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

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.