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

Awebb · 2014-01-06 20:53:13

A downvote system brings out the inner asshole. This is why I love downvoting on reddit, because I only frequent the areas, where being a jerk is appreciated. Downvoting on packages would be somewhat against the idea of AUR votes.

progandy · 2014-01-06 21:12:00

HalosGhost wrote:

But having it be world-editable is kind of problematic. That's why I proposed a git repo as the front-end. Anyone can then submit comments and pull requests, but only the maintainers, TUs and contributors can push commits.
All the best,
-HG

I'm not sure whether git is such a good idea. We would have to create one repository per package I guess. Is that feasable for >30000 packages?

Instead of a wiki, I would rather have something like this: The maintainer manages his official package version. If someone marks it as deprecated/broken, a fixed PKGBUILD can be added. There will be a history for the last ~5 third-party packages ("pull requests" if you think about git). The official download does not change, the visitor has to explicitely choose the outside source. The maintainer can then select a fixed version as the official download or upload his own update.

Awebb wrote:

A downvote system brings out the inner asshole. This is why I love downvoting on reddit, because I only frequent the areas, where being a jerk is appreciated. Downvoting on packages would be somewhat against the idea of AUR votes.

That is my experience, too. You'd have to counter that with a periodic purge of illegal votes and ban of users.
A vote does not say why the package is problematic, either. If the package really has problems, then add a comment that explains it. Other users should know if only the PKGBUILD is bad, the software itself has bugs or something else is the matter.

Last edited by progandy (2014-01-06 21:13:16)

sitquietly · 2014-01-06 21:45:07

karol wrote:

I think Arch wiki is mostly outdated as very few users take time to fix stuff there.

I'll argue that the Arch Wiki is in far better shape than the AUR and that no re-design is required to
make it maintainable and self-healing. It can be perfected just by using the existing mechanisms.

If we're forced into re-envisioning the design of the AUR I still ask why not use a wiki. The software
is available and wikis work well in practice. PKGBUILDs are just text after all and a wiki format
allows for unlimited footnoting and referencing.

I'm not sure but couldn't someone put a page on the Arch Wiki right now that lists package group
names, like Gentoo does with dev-lang, gnome-extra, x11-wm, etc. Each of those pages provides
editable text with links to PKGBUILD pages. Each PKGBUILD page is to contain only the text of
a pkgbuild.

The wiki software provides a history of changes. Almost instantly you have a maintainable set of
PKGBUILDS. Very very small set, but it can grow without further crisis. (IIR)

It would be like the Beyond Linux From Scratch online book with pkgbuilds in place of instructions
to type this command and this command..

graysky · 2014-01-06 21:47:24

...not to be rude, but is this discussion thread serving any purpose beyond just chit-chat? In other words, in the 4 pages of text, are there any deliverable that can or will be acted upon?

karol · 2014-01-06 21:51:25

I don't mind having a discussion first, vote later etc. but yes, this is all non-binding chit-chat.

Inxsible · 2014-01-06 22:02:19

yeah, has anyone of us asked the people currently responsible for maintaining the AUR whether they want or are even willing to implement drastic changes like a git front, or changing it to a wiki or even a complete purge every year?

If they are not interested, then this is a classic TGN thread.

karol · 2014-01-06 22:15:26

I've send a quick mail to aur-dev: https://mailman.archlinux.org/pipermail … 02589.html

jasonwryan · 2014-01-06 22:17:11

The Overlord-in-Waiting and Pierre have both posted in the thread...

karol · 2014-01-06 22:22:26

jasonwryan wrote:

The Overlord-in-Waiting and Pierre have both posted in the thread...

I know and I liked his suggestion very much https://bbs.archlinux.org/viewtopic.php … 9#p1366869 :-) but if we want to make something happen rather than just play "if I ruled the world", I'd like to see how serious Pierre & Co. are about it.

If Our Dear Overlords decide that AUR (or rather the PKGBUILDs) in the current state is not bad enough to be nuked or that our suggestions are all 'meh', this is IMHO TGN.

jakobcreutzfeldt · 2014-01-07 09:36:48

I'm all for the wipe. Nothing else needs to be said in that regard that hasn't already been brought up.

As for preventing future cruft, I think a wiki-style system would be an awful idea. All it takes is one idiot making a malicious change to some package that goes unnoticed for some time to bring the whole idea into poor repute. On the other hand, one giant git repo would be rather unwieldy and a lot of work for whomever is in charge of managing all the pulls.

Why not simply require an extra field in the PKGBUILD that defines the location online where the file is under version control? That way users have a place they can go to submit patches or request a pull/merge. That probably wouldn't require much work to implement. On more of a policy side, it would also be nice to have a way to formally request that a demonstrably inactive and/or broken PKGBUILD be replaced and adopted by a new user (after sufficient warning to the previous maintainer, of course).

More "out there" and probably more work to implement than it's worth, but it would be cool if the whole makepkg/pacman system had a way of making and organizing "forks" of packages, beyond just making a new package and appending a "-foo" to its name. That way people could share all of their minor configuration tweaks to programs without cluttering up the AUR with a million variants of the same program (oh cool, you applied one patch and uploaded it to the AUR...). I don't have a formal, technical definition of what I mean. It's purely in my imagination.

anonymous_user · 2014-01-07 15:37:21

jakobcreutzfeldt wrote:

Why not simply require an extra field in the PKGBUILD that defines the location online where the file is under version control? That way users have a place they can go to submit patches or request a pull/merge. That probably wouldn't require much work to implement.

By file do you mean the PKGBUILD itself? I don't know if many maintainers use version control for them. Also wouldn't this be similar to having the entire AUR on git?

jakobcreutzfeldt wrote:

On more of a policy side, it would also be nice to have a way to formally request that a demonstrably inactive and/or broken PKGBUILD be replaced and adopted by a new user (after sufficient warning to the previous maintainer, of course).

What do you mean by formal? AFAIK, the current method is not unlike requesting an orphan: posting to the mailing list.

Last edited by anonymous_user (2014-01-07 15:37:43)

sitquietly · 2014-01-07 17:58:52

jakobcreutzfeldt wrote:

I'm all for the wipe.....More "out there" and probably more work to implement than it's worth, but it would be cool if the whole makepkg/pacman system had a way of making and organizing "forks" of packages, beyond just making a new package and appending a "-foo" to its name. That way people could share all of their minor configuration tweaks to programs without cluttering up the AUR with a million variants of the same program ...

Have you considered the possibilities offered by the "problem" that AUR packages must be built from source? It would be trivial to do just what you imagine and allow one pkgbuild to build any one of many variants. It MUST be trivial; I've done it. I build my whole system from source this way. A recipe for this AUR enhancement would be

1. Add a package to AUR called features. It just installs a script called "feature" and a config file /etc/features.conf.
feature checks whether features (think of Gentoo USE flags but with a much more primitive functionality) are
set in the FEATURES array in features.conf and optionally writes some text to standard output:

feature feature-name [true-text [false-text]]

(I wrote it myself such that "feature-name" can be a quoted list and the compound "feature" is "true" only if every one
of the features is present (or negated features are absent), e.g.

feature "kde openssl" --enable-x --disable-x
or
feature "kde -java" --enable-x --disable-x

2. Add the features package to the makedepends of tweakable packages in the AUR and use the "feature" command
to select options.

e.g.

my pkgbuild for vlc has samba as an optional feature so the depends array has
depends=(..... $(feature samba smbclient) )

and the configure command has
./configure --prefix=/usr ..... $(feature samba --enable-smb --disable-smb)

My one vlc pkgbuild can build with or without support for kde, oss, pulseaudio, avahi, or samba, and hence with or
without those dependencies.

Documentation can be controlled as a feature. For example my pulseaudio pkgbuild has

makedepends=(.....$(feature documentation doxygen)  )
build() { .....
  if feature documentation; then
    pushd doxygen
    doxygen doxygen.conf
    popd
  fi
  make
}
package() { .....
  if feature documentation; then
    install -d -m755 "${pkgdir}/usr/share/doc/$pkgname/"
    cp -r doxygen/html "${pkgdir}/usr/share/doc/$pkgname/"
  fi
}

In the AUR (but not for ABS) one pkgbuild can easily be written to provide a customizable feature set. In my own work I don't try to
pre-define all possible features or be logically perfect in my choices. I just provide myself with a simple flexible mechanism and then
let the system evolve. A good developement approach just doesn't get in the way of the evolution.

Last edited by sitquietly (2014-01-07 18:06:41)

jakobcreutzfeldt · 2014-01-07 19:02:46

anonymous_user wrote:

jakobcreutzfeldt wrote:
Why not simply require an extra field in the PKGBUILD that defines the location online where the file is under version control? That way users have a place they can go to submit patches or request a pull/merge. That probably wouldn't require much work to implement.
By file do you mean the PKGBUILD itself? I don't know if many maintainers use version control for them. Also wouldn't this be similar to having the entire AUR on git?

Yes, I mean the PKGBUILD itself and any associated files (.install etc). And the point is that they should use version control, not in the least because it would help to manage patches sent by users but also so that users could view changes to the file over time (or the lack thereof). It wouldn't be similar to having the entire AUR on git, assuming you mean in one repo, because it would eliminate the need for having some gatekeepers having to deal with patches/pull requests from thousands of maintainers or users for tens of thousands of packages. As for having all of the AUR in separate git repos on one server, yeah, that'd be fine, except who would want to host and administer that? There are countless source-code hosting services out there. Better to just have the maintainers use one of those.

anonymous_user wrote:

jakobcreutzfeldt wrote:
On more of a policy side, it would also be nice to have a way to formally request that a demonstrably inactive and/or broken PKGBUILD be replaced and adopted by a new user (after sufficient warning to the previous maintainer, of course).
What do you mean by formal? AFAIK, the current method is not unlike requesting an orphan: posting to the mailing list.

If that's the current method, then fine, but it's pretty opaque. Send an email and cross your fingers that somebody notices/cares/does something. Better to have a formal process defined.

jakobcreutzfeldt · 2014-01-07 19:08:04

sitquietly wrote:

In the AUR (but not for ABS) one pkgbuild can easily be written to provide a customizable feature set. In my own work I don't try to
pre-define all possible features or be logically perfect in my choices. I just provide myself with a simple flexible mechanism and then
let the system evolve. A good developement approach just doesn't get in the way of the evolution.

Thanks for outlining your method. I think it would be interesting to see you "release" this (that is, make your features script available on the AUR and somehow encourage people to start using it in the New AUR). That way there could just be one "foo-custom" package in the AUR using features rather than "foo-with-bar-patch", "foo-with-baz-patch", "foo-no-x", "foo-no-gtk", "foo-no-gtk-with-glitter", etc. which would be an improvement.

It still doesn't quite fit what I was imagining, which was poorly defined to begin with (I was picturing something more along the lines of how git-branch works, if you're willing to twist and abstract that analogy in such a way that it eventually makes sense). Anyway, I shouldn't derail the thread too much with that so nevermind.

Lone_Wolf · 2014-01-07 21:50:18

Technically the arch wiki is NOT world-editable, as you need to register an account to be able to edit it.

Packages however are often more then just a PKGBUILD, install files , patches, .desktop files etc are also needed.
some other potential issues if AUR became a wiki :
Consistency : Aur pages have a common lay-out that can't be changed by users.
Upon submitting packages are checked and can be refused if they are not valid package tarballs

How would a wiki implenent that ?
Who is going to write the code for it ?

sitquietly · 2014-01-08 01:10:01

Lone_Wolf wrote:

Technically the arch wiki is NOT world-editable, as you need to register an account to be able to edit it.
Packages however are often more then just a PKGBUILD, install files , patches, .desktop files etc are also needed.
some other potential issues if AUR became a wiki :
Consistency : Aur pages have a common lay-out that can't be changed by users.
Upon submitting packages are checked and can be refused if they are not valid package tarballs
How would a wiki implenent that ?
Who is going to write the code for it ?

Valid concerns. The wiki is probably a bad idea, but I did write code in wiki format a few years back (otherwise know as "literate
programming") and enjoyed working that way. The nodes in my wiki had attributes and any node could be code, with any
associated interpreter (most of my code was icon, awk, or tcl). I suppose it can be done in a shared wiki but I can't foresee all the problems.

My first hunch is to present AUR in the wiki by employing a naming convention to denote any page as a pkgbuild. Every sub-page
of that would be considered an associated file such as *.install, *.desktop, *.patch. A pkgbuild would be "checked out" by
taking account of the naming conventions. I suppose there would need to be an index page that listed all package names so that
any pkgbuild could be checked out using something like wget to pull down the page for the package and all of its children as text
with file names the same as the page titles.

Maybe with an agreed naming convention existing wiki software and infrastructure would be adequate. Any way, my idea was to
suggest that the answers to your questions were:
No one would implement the wiki -- it exists.
No one would write the code for it -- it has been written.

If those assumptions are truly invalid then the idea is also invalid.

karol · 2014-01-09 17:41:44

[RFC] Per-user package submission and management: https://mailman.archlinux.org/pipermail … 02603.html

crondog · 2014-01-09 22:44:22

karol wrote:

[RFC] Per-user package submission and management: https://mailman.archlinux.org/pipermail … 02603.html

For what it's worth, I really like that idea

clfarron4 · 2014-02-25 20:15:08

I don't remember if this was already mentioned, but I would like a reason to be given when a package is flagged out of date, same as with packages in the official repositories. It means I know why it's being flagged (or makes the flagger think about whether it actually needs to be flagged).

artoo · 2014-02-26 15:48:43

I would love to see a "delete pkg" button only for maintainers/uploaders.
I think, but that is only me, that the process of getting a pkg deleted via mailing list shies away for various reasons.
I can't complain, my deletion requests were nicely almost immediately done, but it may be worth a thought by allowing maintainer deletion. A bit more control over the pkgbuild would be nice.

If there was an automatic "out-of-date" flagging, I would propose a 4 weeks time frame to update.
Since arch is rolling, sometimes spare time doesn't allow to update within eg 2 weeks.
You might shoot yourself in the foot with only 2 weeks, and you might get tons of new orphans, because the time frame is too short for maintainers. Just speculation, but also worth a thought if auto-flagging was implemented.

sitquietly · 2014-02-26 18:02:06

artoo wrote:

I would love to see a "delete pkg" button only for maintainers/uploaders.
....

I would like to see a "Packaging Errors" button. Maybe just a "Packaging Sucks!" button. (but not a general Arch Sucks! button )

I often am in a quandry whether to vote for a package that I think should be in the AUR, but whose maintainer has written a bad pkgbuild. In some cases "bad" means it doesn't actually work. Sometimes it means that the pkgbuild is a good example of how to violate all the rules of proper packaging. It would be useful, I think, to be able to vote "for" the package and "against" the packaging.
Maintainers could respond by fixing the package, orphaning the package, or deleting the package. At least they would know that x users think the packaging is wrong without reading all the comments and searching for "+1 -- doesn't work for me either".

Cloudef · 2014-02-26 18:07:54

It would be great if you could contribute fixes to PKGBUILDs.
I've actually written "AUR clone" for PNDBUILDs for Pandora (and future makepnd (makepkg fork))
http://cloudef.eu:9002/ It's still not finished, but it focuses on contribution.

artoo · 2014-03-02 15:54:16

sitquietly wrote:

artoo wrote:
I would love to see a "delete pkg" button only for maintainers/uploaders.
....
I would like to see a "Packaging Errors" button. Maybe just a "Packaging Sucks!" button. (but not a general Arch Sucks! button )

I suppose, this could be achieved with a negative vote count, or a second "packaging quality" vote option. Too many negative votes, e certain limit, will trigger TU review.

I thought about the "delete srcpkg" button.

There may be valid concerns giving maintainers such control.

What if the maintainer could flag the pkg, which requires a reason for deletion, and TUs decide to delete it instead of going to mailing list? A system similar to bug tracking, easy to maintain for the TU.

Last edited by artoo (2014-03-02 15:55:26)

HalosGhost · 2014-03-02 16:26:41

Honestly, I think the easiest way to do some of these things would be to have a flag drop-down box. So, it would have a few options:

out-of-date
bad/old syntax
doesn't build
duplicate

Then, maybe there could be a textbox for the flag drop-down for an extra note (which would include, for example, the link to the duplicated package). This would need to be form to submit, but I think it would make a lot of lives easier.

All the best,

-HG

karol · 2014-03-02 16:29:48

Multiple issues are possible e.g. out-of-date & bad/old syntax, so you should be allowed to tick the appropriate boxes.

Arch Linux

#76 2014-01-06 20:53:13

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

#77 2014-01-06 21:12:00

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

#78 2014-01-06 21:45:07

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

#79 2014-01-06 21:47:24

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

#80 2014-01-06 21:51:25

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

#81 2014-01-06 22:02:19

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

#82 2014-01-06 22:15:26

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

#83 2014-01-06 22:17:11

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

#84 2014-01-06 22:22:26

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

#85 2014-01-07 09:36:48

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

#86 2014-01-07 15:37:21

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

#87 2014-01-07 17:58:52

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

#88 2014-01-07 19:02:46

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

#89 2014-01-07 19:08:04

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

#90 2014-01-07 21:50:18

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

#91 2014-01-08 01:10:01

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

#92 2014-01-09 17:41:44

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

#93 2014-01-09 22:44:22

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

#94 2014-02-25 20:15:08

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

#95 2014-02-26 15:48:43

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

#96 2014-02-26 18:02:06

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

#97 2014-02-26 18:07:54

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

#98 2014-03-02 15:54:16

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

#99 2014-03-02 16:26:41

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

#100 2014-03-02 16:29:48

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

Board footer