You are not logged in.
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
Same idea here.
I imagine an admin front-end too, where TU or whoever can check/mark/delete etc requests generated by the user front-end you describe. But I don't know the inner working of AUR.
Last edited by artoo (2014-03-02 16:32:46)
Offline
Seems like a good idea. Though it should be make so that you have to be signed in, and can only flag a package once an hour to try and prevent spam/abuse.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
I don't know the inner working of AUR.
Offline
Is all this which is discussed here actually considered by someone involved in the development of the AUR or are we just envisioning something without actually discussing its possible implementation?
Offline
AFAICT this is just wishful thinking.
Offline
Nah, we are just waiting for Pierre to find a suitable occasion (the 1st April would be a good one)...
Offline
Is all this which is discussed here actually considered by someone involved in the development of the AUR or are we just envisioning something without actually discussing its possible implementation?
If memory serves, the link to this thread was posted to the aur-dev mailing list, so at least some of the ideas proposed here may have been seen. As to whether or not any of the proposals here will become anything more than just the stuff of dreams, that is up to the ALUR devs.
All the best,
-HG
Offline
If someone writes the code, the devs may accept it.
Offline
@karol
But don't that requires that we agree on one approach first to ensure that all efforts are put into just one solution, and to avoid that we end up having multiple incompatible code proposals?
Offline
But don't that requires that we agree on one approach first to ensure that all efforts are put into just one solution, and to avoid that we end up having multiple incompatible code proposals?
LOL. Like that is ever going to happen...
First person to pony up working code wins.
Offline
I call dibs on writing the first thread complaining that the implemented solution isn't KISS , ignores the Unix philosophy and is ruining Arch forever.
Offline
@karol
But don't that requires that we agree on one approach first to ensure that all efforts are put into just one solution, and to avoid that we end up having multiple incompatible code proposals?
Sure. I didn't mean to say that the thread is useless. If some code gets produced as a result, it has a chance of getting upstream.
Offline
I call dibs on writing the first thread complaining that the implemented solution isn't KISS , ignores the Unix philosophy and is ruining Arch forever.
systemdaur.
Offline
systemdaur.
Does this mean we can finally implement systemd-alurd and alurctl?
Well, I have not yet looked into any of the ALUR's code, but I will do so when I find more free time. Maybe we can get some of the good ideas in this thread realized.
All the best,
-HG
Offline
It's AUR, not ALUR, TLAs rule.
Offline
TLAs rule.
huh?
All the best,
-HG
Offline
Two Letter Acronyms.
...wait.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Two Letter Acronyms.
...wait.
http://en.wikipedia.org/wiki/Three-letter_acronym
The ska band TLA from Dunedin, New Zealand, uses "TLA" to mean "two-letter acronym".
Offline
Just to throw this out there (sorry for the seeming thread-derail), but it's not actually an acronym if it cannot be pronounced as a word. "AUR" can be pronounced, it just doesn't ever sound quite right in English. "Alure" on the other hand is a perfectly valid pronunciation for "ALUR" which is perfect
All right, sorry for the off topic.
All the best,
-HG
Offline
https://bbs.archlinux.org/viewtopic.php?id=168187 -> https://bbs.archlinux.org/viewtopic.php … 3#p1311673 :-)
I would like to be able to link to a specific comment. I know comments can be removed ...
I would like to have something like fluxbb instead of the current comments system, with some ability to use bbcode etc.
Offline
Is it possible to get some consistency between the Package Actions for packages from the official repos and packages from the AUR?
The former look like this:
Source Files / View Changes
Bug Reports / Add New Bug
Search Wiki
Flag Package Out-of-Date (?)
Download From Mirror
while the AUR has a different layout:
View PKGBUILD
Download tarball
Flag package out-of-date
Vote for this package
Notify of new comments
I noticed I can't select (highlight to copy) the lower three AUR package actions with my mouse and I had to type them here. These links are visible only to logged-in users.
I suggest we re-arrange both, like this:
Source Files / View Changes
Download From Mirror
Bug Reports / Add New Bug
Search Wiki
Flag Package Out-of-Date (?)
while the AUR gets:
View PKGBUILD
Download tarball
Vote for this package
Notify of new comments
Flag package out-of-date
I have no idea how often is 'Flag package out-of-date' link hit by accident (I'm talking about AUR), but putting it at the bottom should help a bit.
Offline
orschiro wrote:But don't that requires that we agree on one approach first to ensure that all efforts are put into just one solution, and to avoid that we end up having multiple incompatible code proposals?
LOL. Like that is ever going to happen...
First person to pony up working code wins.
In that case, is it an idea to create a Wiki page with all the ideas, just to keep an overview of what has already been suggested and who is potentially working on what?
Offline
A wiki page to keep track of the suggestions on how to clean up the AUR? NA, I propose a git repo with potential solutions that can be forked for each alternative solution. Either of these could be good additions to the forum discussion we already have here for suggestions on how to clean up the AUR.
But I suppose now we need to figure out a way to decide between the various ways of deciding between the various ways of cleaning up the AUR. I can't help with that as I have to go to work and have a planning meeting with my collegues in which we do nothing but plan our other meetings ... in which we do nothing but....
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Online
Just my 2c.
While a lot of the suggestions in the previous posts do make a lot of sense to me, some do seem to have quite a large change/coding requirement to be able to fulfill, then there is the issue of finding someone willing to take the time to actually implement it.
Wiping the AUR and starting again, while I understand it is to remove the cruft, I think it will damage the Arch brand over time. Arch is famous for the AUR, and wiping it, well, we are dealing with humans, so I can see it taking a veeeeeeeerrryyyyyy long time for packages to be moved across, reducing the once mighty AUR river to a trickle in the desert.
Personally, I think we should stick to the Arch mantra of KISS here.
Obviously, I do not know the inner workings of the AUR and how easy/hard it would be to implement, but I think we should let the system clean itself automatically.
1. A package is flagged out of date (currently generates an email to the maintainer).
[EDIT] 1a. Perhaps require a reason why it's flagged out of date to be submitted. For example Upstream Version, Bad PKGBUILD, Incorrect PKGBUILD format...etc...etc....[/EDIT]
2. After 2 weeks (example time frame only, but basing this on the current 2 week orphaning rule) if not updated, it is automatically orphaned (again an email can be sent to the maintainer advising them this has happened).
3. After 4 weeks (again an example time frame), if no one has picked up maintenance of the package, it is "archived" and removed from the AUR.
This will allow the AUR to self clean, rather than us relying on emails to AUR-general for the TU's to run around and wipe our noses for us....lol. I think something like a 6 week timeframe is ample to allow someone else to pick up the package and update it. [EDIT] And this will free up the TUs from all this current manual work and allow them to concentrate on more valuable tasks, such as picking up very popular packages they are willing to move into community.[/EDIT]
I think this is something that may be able to be automated, of course, correct me if I am wrong.
I don't like the idea of auto-flagging something out of date if the package has not been updated on the AUR for a period of time. As we all know, some upstreams have a very active release cycle, whereas some projects can be quite glacial. So just because a package may have not been updated for 1-2 years, does not necessarily mean it is out of date. So no automation on that front. We will still need to rely on users flagging packages out of date.
This can also allow the addition of another option on the package pages. A request orphaning option, which can work exactly the same as flagged out of date, but is for taking over of an unmaintained package. Currently we email the maintainer and if no response after 2 weeks, we can request the TUs to orphan the package. Lets just automate the process along the flagged out of date process I listed above.
It has been mentioned about adding a delete button for maintainers to delete their packages. Personally, while a good idea, I think it should not just be an auto delete. This case I think should be moderated by the TUs as there may be a compelling case to keep the package, merge it or orphan it, rather than simply just deleting it.
Cheers.
[EDIT]Bloody fat finger typos [/EDIT]
[ADDENDUM]Another thought, you could then perhaps once a year, have an AUR clean up by autoflagging all packages out of date, the system would then clean itself by orphaning and removing packages that are no longer maintained.
So, there are three options to help keep the AUR in a clean and healthy state, which can all be implemented concurrently, and all utilise the exact same functionality.[/ADDENDUM]
Last edited by Padfoot (2014-03-14 22:48:03)
Offline