Though this has got long, I actually think very small simple things would suffice, like a "ReadmeSource" in the right place..
2009/12/5 Peter Pöml poeml@cmdline.net:
Am 05.12.2009 um 10:28 schrieb Rob OpenSuSE:
Am including Factory list, perhaps in 11.3 a better way of making source available to end users, which avoids big load on Build Service and Mirrors is possible?
Uhm, these are two separate issues:
installability of source RPMs on released openSUSE (which you ran into)
the multiplication of sources in the build service (which I mentioned just
because Karsten mentioned the size of the home: namespace in the build service; I tried to set into perspective where most of the space goes.)
Yes, I mentioned as Adrian was talked about dropping source rpm's. Perhaps he meant in very specific area, where they're redundant and not useful but I had a more general impression from the context of the discussion.
Personally I think a disconnected installation ought to be (at least in theory) maintainable independant without requiring external access; it is a USP of FOSS over closed source. Sometimes it gets forgotten but "End of LIfe" (recently openSUSE 10.3) does not mean that OS stops working, or unable to function as well as it did in past. The main issue is noone patches security vulnerabilities.
On project list, a request was made for source by someone unfamiliar with openSUSE suggested an ISO; installing source rpm's with YaST is not working as it did in past for me, because only binary packages are held on most of the download.opensuse.org mirrors.
Since the distribution of downloads to mirrors is transparent, well, just let it work for you. And even if all mirrors would stop mirroring source rpms - that wouldn't change their general availability, because we still offer them, and it wouldn't change the way how YaST installs them.
They are currently available, the thing is it's easy to look in the wrong place, and they are not where one expects to find them. May be binary mirrors could simply include ReadmeSource file, which contains the actual URI as a reminder.
So problems are :
- source rpm's are changed and re-published over frequently by Build
service
That problem affects only the build service - their infrastructure needs more disks, but that's bout it. It shouldn't bother you at least.
It's not about re-publishing by the way. And not about the fact that they change often. It's about duplication. (To fully understand the implications, and in how far they matter, you'll have to read the complete thread that I referenced.)
To give you an example: each source RPMs contains a tarball (the packed sources from the upstream project), a build description, and possible bits like configuration and stuff. If you build Apache, there is a tarball called httpd-2.2.14.tar.bz2 used in the build, and it is included into the source RPM.
<snip>
OK, so the source rpm format could allow an external URI for the source and cryto hash checksums. So long as a local cache copy can be auto-matically retrieved if it's not present locally on a build everyone will be happy.
So, this extreme duplication of sources in the build service is a problem for itself, but it has no effect on users. And the sources that developers are working with are not the source RPMs (which are just a fallout from the build system by automatism), but the original sources. Adrian surely has a point in mentioning that these source RPMs (those of the build service!!) are redundant and utterly useless. It is fully reasonable to suggest getting rid of them _under_ the condition that the original sources are made available anonymously (which isn't the case yet).
Yes. But how is it intended for end user to get the source of packages they're using?
As it stands, the repo system has a source repo, but using rpm build seems to be discouraged (as it builds against current system), and installing the source seems neglected in Software Manager, making it's presence misleadingly pointless.
- source rpm take huge diskspace and bandwidth, for something rarely
required on installed system
See 1), this affects the build service-internal infrastructure, but it's built to handle it. (Which doesn't exclude thinking about optimizations of course :-))
- obtaining the source to build and modify a package on end-user
system (as required by GPL) is less obvious than it was in past
I can't judge - I don't use YaST or something. However the sources are all there, which we probably all agree on. They are accessible through various means (even mirrored, and free to be mirrored by everybody with no restrictions and no exceptions); there's the convenient build service for those who want to work with the sources seriously enough to bother creating a Novell account, and there is an option in YaST (of arguably operability) that makes it easy for everybody installing to install the "feel-good-factor" as well. From what people wrote, there's even a snail mailed DVD, although I cannot confirm its existance.
How obvious all this is - hard to say, but I think, who he who asks will get the helpful pointers at least ;-)
Being thorough I see number of different requirements :
1) Community end user + ought be able to find out how something works and hack on a program without reading openSUSE specific documentation + not have to inquire mail lists, forums etc
2) FOSS checklist - do we have local copy of all the source we use + business wants to be sure, nothing is missing for strategic reasons + FOSS advocate out of principal
3) Convenient License Compliance + online not snail mail + available to all
And if you have ideas how to make things more obvious, I'm sure they are welcome'd by everybody else. There is always somebody who will benefit from it.
Can we simply have seperate hosts in URI's for binary download, binary debug & source packages?
Do you think that http://download-sources.opensuse.org/ would be better than http://download.opensuse.org/source/ ? I don't think so.
Actually yes, because I looked at the repo list likely 100 times, before I noticed that first level directory change. I think it's easier to spot differences at start, or end of a URI, but not in the middle. Once you KNOW the top level directory is different, it is obivous, until then it is easy to miss.
Even a small html & txt format file ReadmeSources, that's visible when browsing the repo at the i586, i686, x86_64, noarch level explaining location of source, and perhaps reminder of what recommended build tools are, fully satisfies me, because I would not waste time searching in the wrong place.
But, fact is, I have not for very long time needed to get & work with distro rpm, in past I would get source rpm, in order to upgrade to newer release of a software package. With Build service, I doubt I need to do this. Maintaining a package, means working within the Build service.
Mostly now, it would be external source projects not supplied.
What about a way to install all the source of used packages?
I never use it, but I thought there'd be an option for this in the YaST package manager.
If that doesn't work, then check bugzilla and open a bug if needed.
Done https://bugzilla.novell.com/show_bug.cgi?id=560868 It definitely worked in SuSE 6.1!! lol