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(a)cmdline.net>et>:
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
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.
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
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.
1) source rpm's are changed and re-published over frequently by Build
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
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
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.
2) 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
3) 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
? 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
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
If that doesn't work, then check bugzilla and open a bug if needed.
It definitely worked in SuSE 6.1!! lol
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org