2009/12/7 Egbert Eich <eich(a)suse.de>de>:
On Mon, Dec 07, 2009 at 10:15:18AM +0000, Rob OpenSuSE
2009/12/6 Egbert Eich <eich(a)suse.de>de>:
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
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)
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 &
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
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
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org