It's time to start something new, AUR2

Romashka · 2006-12-30 13:45:28

IMO, "unsafe" packages are not devs/TUs problem.
If user didn't read License Agreement before using software - it's his/her problem.
I know that <1% read it, but I think it won't matter in curt.

Though laws ...or, no - judges, are so stupid, that their rulings can be like those when some woman won a case when she burned her mouth with coffe in fastfood, because she didn't know it was hot.

iphitus · 2006-12-30 13:46:41

dtw wrote:

iphitus wrote:
We don't know, we don't have the legal advice so we pick the safest option.
Can't we get legal advice? Is there no precedent elsewhere - BSD ports?

there is the SFLC...
http://www.softwarefreedom.org/
but don't know the details.

As for any further discussion on this particular point, unless you are a lawyer in this area of the law, it's not going to be of much assistance. It's something the devs need to chase up, not backyard lawyers.

You may now return to the scheduled AUR2 discussion!

James

Romashka · 2006-12-30 13:52:25

While we are talking about legal stuff,
I want to remind that recent thread about GPL and sorces.
I still think don't must to provide GPLed sources, but I'm not native English speaker and IANAL, so I may be wrong.

fk · 2006-12-30 14:15:02

I think it would be nice that I can access the unsupportet Repo by Pacman

Romashka · 2006-12-30 14:35:31

fk wrote:

I think it would be nice taht I can access the unsupportet Repo by Pacman

I don't think this is a good idea.
We don't want pacman to be bloated, do we?
There are other tools for this.
If you want pacman to be able to use unsupported, then either it should use makepkg or all packages in unsupported should be binary, not just tarballs with PKGBUILD&etc. And this will encourage newbies, and because it's a huge security risk and no guaranty of no breakage, we will get a ton of complaints.
So, it's better to leave things as they are now.
If you wan't easy install from unuspported - you can always use qpkg/aurbuild/yaourt/aurinstall/aurtools+makepkg/etc.

arooaroo · 2006-12-30 17:37:12

1. Regarding AUR support in pacman - I too think it's not a the best idea. I think it's fair to keep supported and unsupported separate. However, I do think that AL should distribute an AURBUILD-like package so that people can use the AUR out-of-the-box, just like they can with the supported repos. The fact that there are two individual programs should help to reinforce the distinction between supported/unsupported and should prod the user to remember that unsupported is just that: unsupported. But the current situation isn't KISS.

2. I hate IANAL arguments because law is not always based on common sense, but then again, nor are some people, which is why the IANAL arguments are flying around because devs fear responsibility for idiots.

IANAL == conjecture and so we are surely going around in circles thinking about potential legal implications. How about we first evaluate a solution based on technical merit and create a "preferred solution". If that solution rings alarm bells, then perhaps it's time to find a nice OSS-friendly lawyer to assist.

However, one must beg the question about what is the position regarding supported packages that are designed to do harm. Think of your partitioning, formatting, file erasing tools. Or let's look at the following scenarios:
a) Stupid user is in the Arch Linux installer and presses OK to the "Are you sure you want to format your hard disks - YOU WILL LOSE ALL YOUR DATA?" even though they didn't mean to == we're covered. (Or at least the devs are happy that the lawyers won't be knocking);
b) User installs an unsupported package from AUR and presses OK to the big warning about the package being unsupported and could do serious harm, the package is run and messes up the hd == run for the hills - are asses are gettin' sued!

Purch · 2007-01-10 19:23:41

- In AUR TU can safe flag pkgbuild's. After package is upgraded the safe flag is gone, this is good. What I had in mind is to add some code so the TU who flagged package safe would get an email to check the upgraded package and flag it again safe if it is ok.

parit pennit siinä

wrythe · 2007-01-16 01:06:22

What I'd like to see is some sort of nice database that contains the package information so that 3rd party scripts that can search AUR (psearch, yaourt, etc) can do so without having the parse the HTML.

mutlu_inek · 2007-01-16 01:29:07

1.)

I would like to see the problem of outdated packges addressed. Many (non-community) AUR packages are outdated because the maintainer has lost interest in maintaining them or even quit using Arch. Some helpful users keep posting updated PKGBUILDs as comments. But this is not really a remedy for the situation, especially if the it continues for many months. There should be an easy way to adopt such packages.

If I understand it correctly, the functions "Adopt Packages" and "Disown Packages" in AUR work only for TUs. We should add a possibility for regular users to apply to a "I want to adopt package" list. TUs then should be notified by email, check the status of the package that is supposedly out of date and reassign it.

2.)

I would also like download statistics. I think seeing how many people use certain packages will motivate people to continue maintaining. (Well, I assume most packages are actually used.)

I am aware that such statistics may be problematic. Is merely viewing a PKBUILD a download? If yes, what if users just check the build or use it as an example for own package builds? If no, what it users copy&paste the PKGBUILD and install it by hand?

Nonetheless, we should come up with a middle way for this.

Romashka · 2007-01-16 09:41:23

mutlu_inek wrote:

I would like to see the problem of outdated packges addressed. Many (non-community) AUR packages are outdated because the maintainer has lost interest in maintaining them or even quit using Arch. Some helpful users keep posting updated PKGBUILDs as comments. But this is not really a remedy for the situation, especially if the it continues for many months. There should be an easy way to adopt such packages.
If I understand it correctly, the functions "Adopt Packages" and "Disown Packages" in AUR work only for TUs. We should add a possibility for regular users to apply to a "I want to adopt package" list. TUs then should be notified by email, check the status of the package that is supposedly out of date and reassign it.

There is already established procedure for such cases, but it seems not many people know about it.
If author doesn't respond by email for some time and someone wants to adopt package he should post to tur-users ML about this and then any TU will orphan this package.

Dusty · 2007-01-16 14:27:17

Romashka wrote:

There is already established procedure for such cases, but it seems not many people know about it.
If author doesn't respond by email for some time and someone wants to adopt package he should post to tur-users ML about this and then any TU will orphan this package.

There's no reason this couldn't be automated though, with a button that says "Propose Adoption" or some such.

Dusty

SchaduwBlink · 2007-01-16 15:16:47

We need a way for someone to do the following:

A way for trusted users/admins of the AUR to "unmaintain" a package for someone that has not been maintaining the package for a while. Do a search for Kerry on the AUR and you will see what I mean. That has gone 7 or more months without an update, so that needs to be taken over by someone else and a way needs to be done to do that. I suggest this, because if it were possible in the current setup, then it would have been done already for that package.

Please do this. It's a must to allow others to take over for those that disappear off the Earth ... well ... Internet.

Cheers.

iphitus · 2007-01-16 22:24:55

SchaduwBlink wrote:

We need a way for someone to do the following:
A way for trusted users/admins of the AUR to "unmaintain" a package for someone that has not been maintaining the package for a while. Do a search for Kerry on the AUR and you will see what I mean. That has gone 7 or more months without an update, so that needs to be taken over by someone else and a way needs to be done to do that. I suggest this, because if it were possible in the current setup, then it would have been done already for that package.

TU's can unmaintain packages. It's a matter of wanting to do so though. We don't want to maintain every package under the sun just because it's been ditched by someone.

If someone else wants to pick it up, post a message to the TU ML, and we'll orphan it for you.

If we were to automate this, how about, after X months of inactivity, the AUR sends an email to the user in question, if they fail to click the link in that email within a sufficient amount of time, then the package is automatically orphaned.

James

Lone_Wolf · 2007-01-17 18:15:43

sounds like a decent solution

Snowman · 2007-01-18 01:05:29

there's already a feature request in the bug tracker for that : http://bugs.archlinux.org/task/3528

Husio · 2007-01-18 11:01:45

wrythe wrote:

What I'd like to see is some sort of nice database that contains the package information so that 3rd party scripts that can search AUR (psearch, yaourt, etc) can do so without having the parse the HTML.

Or SOAP.
I've write script that reads all PKGBUILDs from AUR and put some info into database. It work quite nice and it's very fast. But making database takes about 20-30 min.

Pajaro · 2007-01-21 12:49:08

i would avoid limiting the trust network of packagers to the heart of arch. Let me explain better. I am a trusted user. But not for you. For you i am simply a user. And probably I will stay like this forever. But people that's around me consider me a trusted user.

This means that, though i am trusted, i don't take any advantage of arch, because you don't trust me.

Creating subnetworks of trusted users would allow me to upload binary packages that are downloadable only by users who say that trust me. I can make their life easier, though, since you don't trust me, you won't get affected of my binary contributions.

It would be good to do things like:
You trust me, i trust this user, you also benefit from him. And everything Without the need of having to hang into the irc, forum, or mail list. there could be a subnetwork of trusted users from a university or a village.

Later on, if this subnetwork is proved good, it could join the root network, so you could increase the scalability of trusted users without having to meet personally everybody.

This subnetwork system would also have to have kind of an uncomfortable feature: if a user stops being trusted, all its subnetwork would become untrusted for the user that untrusted him.

This subnetwork system would save compiling time to the subnetworks, and we live in a time in which we have to start to think about saving energy. Global warming is getting too far.

Acid7711 · 2007-01-21 17:55:00

^^^ While that's a good idea in theory, automatically enlisting people into the TUG is generally not a good idea and that's essentially what it's doing, but it's only effecting a limited number of individuals (If I'm reading and interpreting your post correctly)

I do agree though, on some levels, that it would be AWESOME to have Pacman have the ability to pull directly from the AUR repo without the need for ABS hand entries or using 3ed party apps like AurBuild (great app, don't get me wrong). It could start out commented out like the testing/community/etc repos and the individual user could decide to uncomment them or not.

What would be nice about this is, they wouldn't have to be binary 1st off (but I guess even if they were source and people were using them like that, it would almost be as dangerous as a straight binary install since they wouldn't be overlooking the source, but I'm sure a lot of newcomers don't look at the source when they find out about ABS, they just want the program installed), and 2ed it would make a lot of people (myself included and many of my friends) who thought Arch didn't have jack for packages when they first arrived and only later found out about AUR and ABS containing all these great packages. Granted, I've been around the block a time or two with Arch now, and I know my way around the package managers and how things work, how to do them, etc... but many newcomers don't realize this and it seems like a turnoff when highly-used apps aren't available in Pacman without going through ABS.

I hope I'm making sense.

neotuli · 2007-01-22 00:20:01

Thanks for all the input guys! Make sure it gets to the wiki page, though, that format is easier to follow and refer back to later on.

We've reached the point that I'd like to begin the next phase of the project. That means pretty much all of the AUR discussion will be moving to the tur-users mailing list, and I encourage anyone that's interested to subscribe, particularly if there's a possibility that you could contribute code

Mikos · 2007-01-22 12:13:34

I have 2 (for me really important) ideas for new AUR (and I have already added it to wiki):

1.) There should definitely be some XML-RPC interface, because now external utilities (like aurbuild, aurscripts, etc.) must parse HTML pages (which is really wrong approach).

2.) There should be email notifications for package contributors/maintainers about marking their package as out-of-date and about new entry in discussion under their packages.

Esmil · 2007-01-22 14:50:14

I like your idea Pajaro. I have a completely different vision of AUR2 that I'd like to share though. I'd like to get rid of the concept of owning a package completely. Let me explain by describing the life of a package on AUR2:
A user of the AUR2 finds a new app on the net somewhere and would like to try it out. He can't find it in the repos or the AUR2, so he resorts to writing his own PKGBUILD script and gets it to work. Being quite pleased with himself and his new app he decides to share his work with the Arch community, so he starts a new "package/program thread" on the AUR2 and uploads his set of build-scripts, patches etc. to it.
Another user wanting to try the new app finds the thread on AUR2, downloads the scripts and tries to compile the package. He discovers that it actually depends on another package not mentioned in the PKGBUILD, so he fixes it and uploads his improved version of the scripts to the thread on AUR2 with a comment stating why his version of the scripts are better. If he likes the app he probably votes for it to be included in the repo as well.
Another user tries the build-scripts, but can't get it to work properly and don't know how to fix it. Luckily there is room for posting messages under the thread, so writes a bug-report so someone else can try and resolve the problem.
Another user now uses the program daily and would like to stay informed on the latest and best versions of the build-scripts. This is no problem, because with a simple click he can subscribe to all new events to the thread in some suitable manner (e-mail, AUR2 pm's, RSS etc.)
At some point a new version of the app is released. The user who is first to discover this can of course update and upload the new scripts himself or just flag the thread out-of-date. This warns all the users subscribing to this thread and someone will soon update the scripts.
After enough iterations of this bug-finding, improving, discussing and voting has been going on a TU will come by. He browses through the different versions, perhaps tests a few of them, and decides on a set of build-scipts that creates a package suitable for the repo. Using his TU priviledges he then elects that set of build scripts to be the basis of the package in the repo. He'd probably want to subscripe to the thread as well, so he can keep up with new versions of the app. More TU's can of course share this job.

This should remove lots of redundant work. I can't remember how many times I've updated and improved scripts in the AUR before installing them, because the owner wasn't on top of his package. Yes, even packages owned by TUs (no need to mention a recent example .
Socially this also enables lots of Arch users to feel they are part of and contributing to a community without actually commiting themselves to any further work. Much like wikipedia's really.

TUs can of course still write and improve compile scripts and elect their own versions to be sent to the repo, so it shouldn't hinder their work too much. Only now their work is made more visible. It will probably add a bit more "moderator work" such as weeding out duplicate threads and banning silly users. As I see it though, this is more than made up for by the vast amount resources TUs can draw upon for testing and writing the scripts. A TU embracing this idea should thus be able to maintain more packages in the repo, as in most cases he only needs to test everything works before electing a new package to be included in the repo.

I think thats enough writing from me. Thanks for reading this

phrakture · 2007-01-22 16:26:32

Actually, the trust network thing is a pacman idea I had floating around. For some time, but really had no idea how to implement something of that magnitude.

Basically, I wanted to do it similar to the way ssh works when you ssh to a new host:

OMG WARNING! This package is made by:
   Foo Bar <foo>
   key: 3r230fj308ru329ur04jr2o3irh
Who is currently untrusted by you.  Would you like to trust this user? yes/[no]

That idea is that each user would have a public key which is added to anything they package. If a key is NOT added, the package will require something extra (perhaps a "AllowUntrusted = True" config option?) to install. There would be additional switches to auto trust / untrust a user, and perhaps load trust keys from a file (i.e. for the devs, would could cram all keys up at some URL somewhere).

Again, I never thought much about it... just rolled it around in my head. With a system like this, adding a trust network to the AUR might be cool. Perhaps we could implement some system like: if the user is trusted by > 10 users, allow them to upload binaries... /me wonders

phrakture · 2007-01-22 16:32:19

Second idea, along the lines of what Esmil said:
A "propose changes" function would be cool. Lets think in thread-speak like Esmil was doing:

When the second user makes a better PKGBUILD, he clicks "propose changes" and uploads a tarball the same way the original user would. Internally, this may be saved, but the front end runs a diff algorithm on his changes, and adds some fancy colored output to the thread:

- foo=bar
+ foo=winnar!

Perhaps users could click some "accept changes" button or something so we could automate that process.... but that might be too complex.

mOLOk · 2007-01-22 16:43:14

what about a cvs/svn (read/write) access to unsupported?
would be this too tricky?

sh__ · 2007-01-22 17:35:46

phrakture wrote:

Again, I never thought much about it... just rolled it around in my head. With a system like this, adding a trust network to the AUR might be cool. Perhaps we could implement some system like: if the user is trusted by > 10 users, allow them to upload binaries... /me wonders

Better make it like

if the user is trusted by > 10 already-trusted-users

Otherwise someone could create a number of dummy accounts, set his account as trusted by all of them, and then pollute AUR with trojaned binaries.

Arch Linux

#26 2006-12-30 13:45:28

Re: It's time to start something new, AUR2

#27 2006-12-30 13:46:41

Re: It's time to start something new, AUR2

#28 2006-12-30 13:52:25

Re: It's time to start something new, AUR2

#29 2006-12-30 14:15:02

Re: It's time to start something new, AUR2

#30 2006-12-30 14:35:31

Re: It's time to start something new, AUR2

#31 2006-12-30 17:37:12

Re: It's time to start something new, AUR2

#32 2007-01-10 19:23:41

Re: It's time to start something new, AUR2

#33 2007-01-16 01:06:22

Re: It's time to start something new, AUR2

#34 2007-01-16 01:29:07

Re: It's time to start something new, AUR2

#35 2007-01-16 09:41:23

Re: It's time to start something new, AUR2

#36 2007-01-16 14:27:17

Re: It's time to start something new, AUR2

#37 2007-01-16 15:16:47

Re: It's time to start something new, AUR2

#38 2007-01-16 22:24:55

Re: It's time to start something new, AUR2

#39 2007-01-17 18:15:43

Re: It's time to start something new, AUR2

#40 2007-01-18 01:05:29

Re: It's time to start something new, AUR2

#41 2007-01-18 11:01:45

Re: It's time to start something new, AUR2

#42 2007-01-21 12:49:08

Re: It's time to start something new, AUR2

#43 2007-01-21 17:55:00

Re: It's time to start something new, AUR2

#44 2007-01-22 00:20:01

Re: It's time to start something new, AUR2

#45 2007-01-22 12:13:34

Re: It's time to start something new, AUR2

#46 2007-01-22 14:50:14

Re: It's time to start something new, AUR2

#47 2007-01-22 16:26:32

Re: It's time to start something new, AUR2

#48 2007-01-22 16:32:19

Re: It's time to start something new, AUR2

#49 2007-01-22 16:43:14

Re: It's time to start something new, AUR2

#50 2007-01-22 17:35:46

Re: It's time to start something new, AUR2

Board footer