On Sunday 26 February 2006 18:57, Boyd Stephen Smith Jr. wrote: > > > My proposal at this point, would be for an additional restriction on > > > packages based on a new UPSTREAM variable in the ebuild itself, > > > ACCEPT_UPSTREAM variable in make.conf / the environment, and the > > > package.upstream file in /etc/portage. Stephen and I have talked about this before. The real fleshed out idea is meant to be for a user that might want to follow a package as it moves from alpha->beta->release. While the overall stability of the system might be compromised by globally adding an ACCEPT_UPSTREAM=BETA an individual may be willing to make that compromise to test new applications and provide upstream bug reports before a package has made it to final release.
> > I read your previous posts about this as that you wanted it to be easier > > to get beta versions but what you want is in fact the exact opposite - > > further restriction. Now I get it. I don't envision it as further restriction, instead it's a way to add seperation of ebuild/software stability. Imagine that I have a package that is in early alpha state and very unstable. However the ebuild for that package does not hurt the system, it's proper and conforms to portage and plays nicely. Under the current system if my ebuild was added to portage it would be masked with package.mask. Under the new system it would not be in package.mask, instead a user would have to set ACCEPT_UPSTREAM=ALPHA or set mypackage ALPHA in package.upstream. This also facilitates cvs ebuilds nicely by not having to hard mask everything, but instead making the user choose the system's level of stability. Of course the defaults would be sane, but then the user could override it globally or locally to each package. This would clean package.mask up and make it purely for misbehaving ebuilds. > I'm imaging the default provided by the base profile would be > ACCEPT_UPSTREAM="RELEASE BUG_FIX SECURITY_FIX" so that packages with > UPSTREAM="BETA" (or HEAD, SNAPSHOT, ALPHA, PRE_RELEASE, RELEASE_CANDIDATE, > alia al) would not be installed. (Until you changes your ACCEPT_UPSTREAM > in make.conf or edit /etc/portage/package.upstream) Let's take a real life example of the cloudiness of the current situation. If you run ~arch right now and update your system it will pull a new kernel in even if that kernel is a release candidate. The ebuild is clean and installs properly and is not in package.mask, however if you don't want release candidate kernels there isn't an easy way to do it and only allow released version. Under the new system the kernel ebuilds would still be handled the same way (not placed into package.mask), but the user wouldn't get a release candidate kernel unless they say ACCEPT_UPSTREAM=RELEASE_CANDIDATE or set the kernel up that way in package.upstream. Another example that sticks out in my head. In the run up to KDE 3.5 I wanted to follow all the ALPHA, BETA and RC releases so I could file bug reports and make the final version better. There wasn't an easy way to do this and the list of packages to unmask was enourmous. Somewhere near beta2 all the ebuils were good, so it could be cleanly merged, but you had to go through the unmask dance. Under the new system once the ebuilds were clean, they would move out of package.mask and any user with the appropriate ACCEPT_UPSTREAM/package.upstream settings could test the new KDE. > "If there's one thing we've established over the years, > it's that the vast majority of our users don't have the slightest > clue what's best for them in terms of package stability." > -- Gentoo Developer Ciaran McCreesh I can't believe he said that! What he might have meant is that we should provide sane defaults to our users so newcomers don't get hosed systems due to us requiring intimate knowledge of the system. While we shouldn't make unsafe policies at the global level we should allow advanced users to do as they please. -- Zac Slade [EMAIL PROTECTED] ICQ:1415282 YM:krakrjak AIM:ttyp99 -- gentoo-user@gentoo.org mailing list
