On 11/03/2010 08:01 AM, Lars Müller wrote:
On Wed, Nov 03, 2010 at 12:44:04AM +0100, Stephan Kleine wrote: [ 8< ]
That leaves out the main issue. The stuff in Contrib is version frozen and therefore any security fixes need to be backported and the packages in there need to be maintained.
I believe - and with Samba we've proofen - this "version frozen" policy as inadequate.
All depends from the dependencies. For example a kernel and glibc version change more likely will break working setups.
While a version upgrade to Samba worked well for several openSUSE and SUSE Linux Enterprise products. As an official update and not only as we offer packages from the network:samba:STABLE and TESTING repositories of the openSUSE Build Service.
For some components of the system we need something like rolling updates. Or is any of you still happily and satisfied using the initial Firefox as offered for SUSE Linux Enterprise 10 or openSUSE 11.2?
Rolling updates for certain parts of the distribution are probably the best approach to the "stuck with very old version" problems. This would also make the "simple maintenance model" you outline below more feasible. However, this does not address the issue of how to get a package into the distro in the first place.
There is nothing like one simple policy. Reality is sucking complex. ;)
Who will do that? If the original submitter is willing to do that he prolly will already submit it to Contrib so I don't see how that will change besides collecting more unmaintained packages in Contrib which isn't really what we should want.
Take the exim example. As I'm using it I'm quite happy to help and complained as soon as it should get dropped.
I'm never going to work on a security update for exim. All I'm willing to do is to keep the exim package in openSUSE on a current level. If there is a security issue I would address it with the new version.
I think there are a lot more potential contributors in this boat. These contributors would be willing to keep one or more packages up to date, but when it comes to fixing code or back-porting then things probably become iffy. Thus having a more lenient policy w.r.t. version changes via updates would probably open the door for more contributors. As simply the maintenance load is reduced by not having to back-port anything and being able to address bugs with a version bump from upstream. Still we need to look at the initial hurdle of the double submit, and being a "blessed" maintainer of a devel project to get stuff into :Factory or :Contrib. Yes, trust and quality of work do come into play. However, there are loads of package opportunities (Perl, Python, Ruby....Applications and modules) where the upstream code has some kind of testing and what is really needed is a person willing to push the version for every oS release and in between if needed due to some kind of bug. I claim, and maybe I am wrong, that the current policies and procedures keep these types of packagers away and subsequently packages out of the distribution. Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Software Engineer Consultant LINUX rschweikert@novell.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org