Time from submission to availability in "unofficial&quo

Xentac · 2003-11-16 03:19:40

I've got a better idea...

How about certain trusted archlinux users get access to their own user repos (TUR - Trusted User Repos). From there people can submit packages to the trusted users to add to their own repos instead of having them sit in incoming.

Then if people want access to these packages they just need to add someone else's TUR to their pacman.conf file.

Obviously you wouldn't do that without trusting the user yourself. These people would be people in the community who have already shown their interest in furthering archlinux (by making packages and helping others).

Sound like a good idea? I've already started on the software and have an initial test group to try it out. What I need to know is if you people would actually use them. They seem like a good idea to me... but I thought of it (not by myself... a lot of the other developers had input).

I just want to stress that these repos would be run by users and are not the responsibility of the Archlinux developers... if they hose your system, it's the user's fault, not ours

sarah31 · 2003-11-16 04:13:46

i prefer TURs to any sort of testing repo. since testing would still require some developer to be invovled and since it would be a repository complete with pacman support people would still consider any problems with to be a developer's problem to solve.

keep in mind that with it in repo format a developer would be the one that has to upload the package and add the PKGBUILD to the cvs repository and then there would be all the bother of cleaning up if it were moved to an "official" repo. to me that implies that a developer is very responsible for the package. to allowusers access to this repo presents a whole load of security concerns.

TURs on the other hand are all user maintained and issues of with them are up to the users to solve. when a packages passes scrutiny though it would be a a much quicker process to get them upstream to the repos.

dp · 2003-11-16 10:52:38

sarah31 wrote:

i prefer TURs to any sort of testing repo. since testing would still require some developer to be invovled and since it would be a repository complete with pacman support people would still consider any problems with to be a developer's problem to solve.
keep in mind that with it in repo format a developer would be the one that has to upload the package and add the PKGBUILD to the cvs repository and then there would be all the bother of cleaning up if it were moved to an "official" repo. to me that implies that a developer is very responsible for the package. to allowusers access to this repo presents a whole load of security concerns.
TURs on the other hand are all user maintained and issues of with them are up to the users to solve. when a packages passes scrutiny though it would be a a much quicker process to get them upstream to the repos.

that's actually what i think of ... sarah31, thank you for your productive comments, as i never had think about the practical consequences of a testing-repo ... from this point of view TURs are exactly what we need (if i understand it right)

what i understood of TURs:
-they are just a repo like others on the archlinux.org server (as often users, like me, do not have a chance to publicate files on the internet, as no fix ip is given to normal people without paying extra --- any idea how to get free server-space on a isp??)
-they are TU-driven ... no maintainer is needed
-they are per default commented out in pacman.conf
-they include all incoming-packages
-they are a really great idea to get packages from incoming installed on your machine locally very fast (since most of packages in incoming are working fine ... at least me, i test my packages before i submitt them to incoming ... but some details are still left out, i forgot --- that's why it is actually a great thing not allowing normal users to post directly into official repos)

farphel · 2003-11-16 14:52:47

If I understand TURs correctly, they would serve as a sort of 'filter' to incoming packages.

Right now, with /incoming, developers have to wade through tons of packages from users with a varied amount of skill building packages - a lot of developer time is spent on fixing minor problems with PKGBUILDS etc.

TURs could solve this problem where the 'trusted user' provides initial reviewing/testing of the 'normal user' submitted package. If the package passes initial testing/review, it gets included in their TUR. Other 'normal users' can then pull the software from the TUR in the normal pacman fassion. So, as I said, it becomes a 'filter' for incoming packages and would probably displace the traditional /incoming.

However, one thing I'm not clear about is what packages can go in a TUR? A TUR has the potential to really screw up users if the TUR starts accepting 'tweaked' or beta packages for software that already exists in a main Arch repository. The latest KDE 3.2betas come to mind; if a 'trusted user' decides to include the 3.2betas in their repository, that has the likely potential of causing conflicts with packages from the main Arch repositories. Personally, I would only want to use packages from a TUR if I knew it wouldn't cause problems with packages from the main Arch repos. However, I'm sure there are plenty of users that would like to see a 'Xtreme TUR' where they could get their hands on the latest 'tweaked' or beta software.

What is the general consensus on TURs? Are they to be used as a 'filter' for incoming packages and intended to be stable and non-conflicting, or will there be TURs for the latest bleeding edge software? Or both?

farphel

kritoke · 2003-11-16 15:02:48

I think these TURs would be applications that do not exist in pacman itself. Otherwise things could get a bit crazy, it would be similar to the problems one would have if someone was both using stable and current at the same time. Things could get real confusing real quick and probably could break a few things. I think the tweaked and modified packages should still remain in incoming because of this potential for breaking installations and such. Although it would be nice to have the KDE 3.2 beta accessable to arch users, it really would take up excessive space and bandwidth. Although it did take me like 10 hours or more to compile it all, it would seem that is the best way to do this is to have a certain place to throw unofficial PKGBUILDs like someone mentioned before and have them compile the things themselves.

Kritoke

deepfreeze · 2003-11-16 15:13:26

The way I view TURs is this...use them at your own risk. They may contain packages of "beta" quality or that have been tweaked in one way or another if the TU desires to put them there. The trusted users aren't going to be pulling packages out of /incoming to add to their repos. Rather, they are going to have a place to post their own packages and accept packages from other people that they trust, instead of putting them in /incoming. Considering that the people running these repos are trusted users, I would hope that buggy, crash-prone or otherise bad programs wouldn't be included, but if you don't feel comfortable with the packages one particular trusted user is including in their repo, you do not have to connect to it via pacman.

The whole purpose of the TUR is to provide unofficial maintainers for packages which is a great thing and serves 2 purposes. By actually having them in a repo, users can connect to it via pacman and install them without them being in official repos. And it makes the process of moving them to official repos easier because in order to get into the TUR in the first place, one would hope that the package has already been tested to some extent. I really look forward to seeing this in action

kritoke · 2003-11-16 15:36:13

So we can have the tweaked or beta versions of packages that already remain in the official pacman? If so, then I think a new feature to pacman might be to have some sort of flag that you can set if it is a beta, so maybe have a setting in pacman.conf that asks if you want to install beta/tweaked stuff or not.

Kritoke

farphel · 2003-11-16 17:09:06

I see more benefit from a single one-and-only-one TUR which is really just a way of turning /incoming into its own repository rather than a bunch of separate TURs. A good example of how multiple TURs could hurt Arch overall would be PHP. The default PHP in the Arch repositories is compiled with a certain set of features, but not all users agree on those features that are included. Sure they can use ABS to tweak it to their satisfaction, but I forsee the TURs as places where these tweaked builds would reside. New Arch users wanting to use PHP would then have the following options for installing PHP: 1) Use the default from the ARch repos, 2) Use ABS, or 3) Use one from the many TURs. Very confusing for newcomers, IMO.

What I think makes more sense is making a single TUR that 'enhances' /incoming. There are a few TU's that have access to placing packages from the traditional /incoming into the TUR. In essence, the TU's act as a pre-test/pre-validation step for packages making it into the main Arch repos. The TUR only contains software that does not exist in the main repos and it also does not contain beta/cvs versions of existing software.

Normal users still submit packages to /incoming, but the TU's move them from /incoming into the TUR after they have reviewed/tested. Normal users can still enable/disable the TUR via pacman.conf. Once a package has lived in the TUR for a while, or has a good user base without problems, it then migrates into the main Arch repos.

I just don't have a good feeling about having multiple TURs.

Xentac · 2003-11-16 19:08:02

Any packages that the TU of that repo wants to put into them can go in. I suggest to all the TUs that they don't upload any packages that conflict in name with offiicial packages... that's just uncool. Instead, if they reall need something named the same they can use 'provides'.

Arch Linux

#26 2003-11-16 03:19:40

Re: Time from submission to availability in "unofficial&quo

#27 2003-11-16 04:13:46

Re: Time from submission to availability in "unofficial&quo

#28 2003-11-16 10:52:38

Re: Time from submission to availability in "unofficial&quo

#29 2003-11-16 14:52:47

Re: Time from submission to availability in "unofficial&quo

#30 2003-11-16 15:02:48

Re: Time from submission to availability in "unofficial&quo

#31 2003-11-16 15:13:26

Re: Time from submission to availability in "unofficial&quo

#32 2003-11-16 15:36:13

Re: Time from submission to availability in "unofficial&quo

#33 2003-11-16 17:09:06

Re: Time from submission to availability in "unofficial&quo

#34 2003-11-16 19:08:02

Re: Time from submission to availability in "unofficial&quo

Board footer