2009/12/7 Egbert Eich email@example.com:
On Mon, Dec 07, 2009 at 10:15:18AM +0000, Rob OpenSuSE wrote:
2009/12/6 Egbert Eich firstname.lastname@example.org:
One use for src.rpm is after a release is not supported, at least in theory it's possible to backport important updates, or have someone look into a new bug which suddenly manifests after end of official support, or say when a program frustratingly refuses to run virtualised on a current machine because it doesn't recognise the CPU as i386 family. Also not needing to be "online" and connected with openSUSE or Novell, provides more security against future unforeseen events.
If this is really the plan, wouldn't it be better to create a project in ones home and build the security maintenence packages there? This way one could share the results with others instead of keeping them on the local machine.
Don't think that fits in with the management type mindset, who want to "have the source", and hope for quick hack. Having the src rpm, lets you do it either with rpm build options, or using SuSE build tool that builds a clean root from the GM files.
The rpm format is defined so it's easy to extract the files with tools. Actually on other distro's to. I have rescued systems via rpm, using other distro's to boot from for example, in chroot(8) environments.
Any competing format, would hopefully be similarly convenient.
My main use for src.rpm has actually been with 3rd party software, where I've needed to alter spec files, and make configure patches to build manageable packages. In the past, end users have also rebuilt distro's to use different compile options for example "RevHat".
What would be the difference if there was a read only osc access? You can download the content of the src rpm, modify it and use build on your local machine to run the entire rpm/srpm build process. For this you don't need a srpm package hosted - you could still distribute your modified srpm.
I'm not an "objector", just if there is change then those are the sort of things that folk need to be able to do, even if they don't actually do them very often, the capability (in theory) matters.
Not being reliant on the project, or Novell matters. Say MS bought Novell for instance in a take over. All of a sudden upstream would be untrusted, and I'd be wanting to inspect updates for tom-foolery.
If source was to be provided another way, like build service, the project would need to make the method much clearer. We "know" how rpm works, and that generates expecations, currently the updates hierarchy has src directory in the hierarchy with ARCH dirs (like i586, x86_64 & noarch).
For 'build' try 'man 1 build'.
Have used it, the version was doing stuff with rpm's and doing an rpm build for me, so it wasn't so different.
Also what was delivered at GM and via update, ought to be archiveable by end user, so needs like the OP's who requested source ISO by download can be met.
Hrm, end users archive things ops request ... is this a very likely scenario?
Well if one person like Matt wants to do it, they need to be able to. Knowing one can download the src rpm & rebuild system packages, matters to more than actually tinker with the packages.
If it's not easy then the bar to being an active community contributer is higher. Even if developers themselves generally would work with make, and release a source tar ball; for sysadmins doing customisation something fairly convenient like rpm is a help.
Using alien to convert packages is good sometimes as well, even if it does not appear in an use cases and work flows for "typical" end users.