Am 05.12.2009 um 13:46 schrieb Rob OpenSuSE:
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.
Indeed, I thought about the same! I think that would help a lot - it would help all people looking at that place, which is indeed a logical place to look. In addition, since the file would be replicated to the mirrors, the information would spread to those additional places. Talk to Adrian and Coolo, they can get that arranged I'd think!
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.
Well, what is the use case for end users to get the sources? What do they intend to do with it - how can we help them? Is it just about having the sources installed, out of interest? That needs a functionality in YaST. Is it to rebuild things with changes? We'd point them to do what everybody else does, namely using the build service to fetch the sources and get the required build environment at the same time. Is it to check how the package was built, and with which patches? Source RPMs are fine for that, but so is the web interface to the sources. I can think of more use cases for source RPMs (e.g. package maintainer from another distribution wants to compare his work), but for end users that's about all I could think of. Help me ;) I think it would be easier for me to suggest a way for how the end user might best get the sources, when having a clearer picture what the intention is. (Not questioning the need as such, or the desire for whatever reasons.)
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.
I don't think that this would help you; I'm rather convinced of the opposite. If the files are on the same host (the one you are looking at), you have at least a chance to find what you look for. If the files are on a different host, you can stare at the listing as long as you want, to no avail.
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
By the way, does the functionality take care of updates as well, and keeps the installed source RPMs updated? Otherwise it'd be quite useless (even dangerous). And does it make sure not to overwrite sources that the local user may have modified? If not, it's a pain. And while I'm at asking silly questions, does installation of source RPMs work at all, without each source RPM overwriting files of another source RPM by accident, if not every name is globally unique? Did you know that all files of all source RPMs are installed into a single directory - /usr/src/packages/SOURCES? And the best of it all, you cannot query the RPM database to find out which files belong to installed source RPMs - rpm just throws them at the system, and doesn't take note of what it puts where, as it does for binary RPMs. Yes, it's really primitive :-) Nothing you could seriously work with. But if you want the above mentioned functionality, you'd probably want it working in complete. No? Let's face it, source RPMs are the undeads of a dark past, only there for archival and no developer wants to work with them, because it'd be a total pain. (Archival however is good. As good as build service hosting might become, it may as well lead into a trap discussed here: http://esr.ibiblio.org/?p=1282 , http://esr.ibiblio.org/?p=1295 , http://esr.ibiblio.org/?p=1302 . The points made there center around the thesis: "Hosting sites are data jails." Source RPMs are a least common denominator, and suitable for storage as well as for import of data elsewhere. [They completely lack history though, apart from a cropped changelog text, which is of course a major shortcoming.])