On Sun, Dec 06, 2009 at 07:54:49PM +0100, Stefan Seyfried wrote:
On Sat, 5 Dec 2009 11:47:43 +0100 Peter Pöml poeml@cmdline.net wrote:
Which brings up the question: couldn't the source RPM be assembled on the fly as soon as somebody wants to download it? There is (crappy ;) version control in OBS, and you "only" need to record which revision built the binary RPM. Then if someone wants the source RPM for this revision, you just pack it up and send it to him.
Should be an interesting Project to implement ;)
This brings back the question why we need the source RPM at all. The only reason I could think of is that people using other distros can easily download out sources. If openSUSE users would either resourt to OSC or to the software installation tools shipped by openSUSE (zypper, YaST, ...) we didn't even need SRPMS at all. Those tools could be modified to use OSC to download the sources from the build system. This would just require meta information about the location of the packages in the build system and an anonymous read only access. Implementing this would be a more worthwhile project than tools that would generate SPRMS from the build system. Additionally the sources could be installed in saner places than /usr/src/packages/SOURCES where they are currently installed by default. Which - as Peter already stated - is a dangerous palce when installing sources for more than one package.
Cheers, Egbert.
2009/12/6 Egbert Eich eich@suse.de:
This brings back the question why we need the source RPM at all. The only reason I could think of is that people using other distros can easily download out sources. If openSUSE users would either resourt to OSC or to the software installation tools shipped by openSUSE (zypper, YaST, ...) we didn't even need SRPMS at all.
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.
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".
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).
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.
On Mon, Dec 07, 2009 at 10:15:18AM +0000, Rob OpenSuSE wrote:
2009/12/6 Egbert Eich eich@suse.de:
This brings back the question why we need the source RPM at all. The only reason I could think of is that people using other distros can easily download out sources. If openSUSE users would either resourt to OSC or to the software installation tools shipped by openSUSE (zypper, YaST, ...) we didn't even need SRPMS at all.
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.
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.
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'.
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?
Cheers, Egbert.
2009/12/7 Egbert Eich eich@suse.de:
On Mon, Dec 07, 2009 at 10:15:18AM +0000, Rob OpenSuSE wrote:
2009/12/6 Egbert Eich eich@suse.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 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.
On 7/12/2009 8:26 AM, Egbert Eich wrote:
On Sun, Dec 06, 2009 at 07:54:49PM +0100, Stefan Seyfried wrote:
On Sat, 5 Dec 2009 11:47:43 +0100 Peter Pömlpoeml@cmdline.net wrote:
Which brings up the question: couldn't the source RPM be assembled on the fly as soon as somebody wants to download it? There is (crappy ;) version control in OBS, and you "only" need to record which revision built the binary RPM. Then if someone wants the source RPM for this revision, you just pack it up and send it to him.
Should be an interesting Project to implement ;)
This brings back the question why we need the source RPM at all. The only reason I could think of is that people using other distros can easily download out sources. If openSUSE users would either resourt to OSC or to the software installation tools shipped by openSUSE (zypper, YaST, ...) we didn't even need SRPMS at all. Those tools could be modified to use OSC to download the sources from the build system. This would just require meta information about the location of the packages in the build system and an anonymous read only access. Implementing this would be a more worthwhile project than tools that would generate SPRMS from the build system. Additionally the sources could be installed in saner places than /usr/src/packages/SOURCES where they are currently installed by default. Which - as Peter already stated - is a dangerous palce when installing sources for more than one package.
Cheers, Egbert.
My understanding, from (very) earlier version of SuSe Linux when I started using it, it was to comply with the Linux GPL.
Not sure if it's still now though.
scsijon
On Wednesday 09 December 2009 18:16:15 scsijon wrote:
My understanding, from (very) earlier version of SuSe Linux when I started using it, it was to comply with the Linux GPL.
Not sure if it's still now though.
It is simple - you either comply with GPL or you don't distribute GPLed software, so openSUSE does comply with GPL.
Sources are available for each and every package that is delivered. Everyone can have them using http://download.opensuse.org/source/distribution/11.2/repo/oss/suse/src/ not to mention development repositories and openSUSE Build Service.
That sources are not advertised as prepackaged binaries is normal as skill level of people able to use sources should be much higher then average user in search for software, so no one came on idea that browsing http://download.opensuse.org/ is some special procedure intended to obscure existence of sources.
I'm actually surprised to see so many comments here.
-
Egbert Eich -
Rajko M. -
Rob OpenSuSE -
scsijon