Devil's advocate comments below...
Thus spake efocht ([EMAIL PROTECTED]):
Hi,
I agree to Dann, can't see a legal issue here.
I'm not entirely sure Dann was saying there isn't a legal issue here,
but that the legal risks might be considered reasonable. However, I
can't tell if Dann is saying "go for it", "don't go for it", or "leave
me out of the decision." Dann?
The vanilla kernel is available
from thousands of sources and mirrors. And GPL doesn't require one to provide
the source, just to provide it upon request. Keeping it ready for download is
good enough. And if kernel.org is down at the very moment somebody wants to
find the source, it will be certainly back up within a day or so. I also don't
fear that the kernel source will disappear: the oldest kernel I could find at
kernel.org was from 1994, so more than 11 years old.
I agree with this, and believe it _extremely_ unlikely that the kernel
source that someone wants to find should not be available for at _least_
three years after we do a release, if not for decades.
I only see practical issues for packaging (or not packaging) kernel sources
with the srpm. As said, I prefer not to pacage it. People who build frequently
have the workaround of keeping the source in /usr/src where the build process
will pick them up. And OSCAR svn repositories won't be bloated with huge
binary SRPMs...
Hmmm. We shouldn't make this decision based on the OSCAR repository,
but it is a good case example. I'm sure this is something that goes
through the minds of other repository managers too.
(OTOH: some of the small package were really poorly
accessible, I wouldn't mind the small opnes to come with the SRPM).
Agreed.
Regards,
Erich
On Wednesday 14 December 2005 21:28, dann frazier wrote:
On Wed, 2005-12-14 at 13:47 -0600, Brian Elliott Finley wrote:
> Bernard recently raised the issue that the SI source tarball only has
> the source for the kernel on which it was created. This raised the
> question of: "Do we include the kernel source for all architectures?"
>
> The problem: that would make for a really honkin' SI source tarball.
>
> Erich Focht's comment (paraphrased): "Don't include the kernel source at
> all, let the getsource tool handle that. The kernel.org mirrors are
> very reliable."
>
> I'd like to come to a conclusion on this quickly, and the crux of it is,
> from an open source perspective, is there anything wrong with us
> providing the kernel source by referencing the URL at which it can be
> found?
Legally (and IANAL):
Standard GPL - we must either provide the source or provide a written
offer for providing the source on request for the next 3 years. This
doesn't mean you have to bundle it - but not doing so is a risk (as is
sourceforge & all mirrors disappearing, etc). This risk maybe something
we're willing to accept, but also be aware that we're passing this
liability onto folks that redistribute SIS.
Here are two ideas:
1) Keep a copy of every source file that we use in any of our
binary releases. Post them up on download.sisuite.org (which
we should move to the svn.sisuite.org machine).
2) Modify the build system to produce two source tarballs. One is
full source, and one is SI code only. Users and package
maintainers could choose what they wanted to re-distribute.
Functionally:
This means that anyone who wants to build SystemImager has to have their
build system on the Internet, and has to have the bandwidth to pull a
large file.
Heh. Won't they most likely get the kernel source via the Internet
anyway? Whether as a seperate download or as part of our source
tarball?
And kernel.org has gone down for multiple days before...
But I would be very surprised if all of mirrors.kernel.org has ever been
down at the same time.
SuSE didn't like a build hitting the net, but they decided not to pick
up SIS anyway.
They did, however, pick up Flamethrower, oddly enough. Using it to
multicast rpms out to autoyast clients.
This wouldn't work for Debian either, but I have to do a
different kernel for Debian anyway (non-free issues).
Historically, I'd tried to keep all archs on the same kernel so only one
tarball is necessary.
I'd like to do that, but we've never been able to do that so far.
Perhaps with 3.6, udev, and uyok, we can go with a more generic kernel
config for the standard kernel, and leave uyok to support the oddities.
And maybe even achieve a common kernel source.
--
Brian Elliott Finley
Mobile: 630.631.6621
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Sisuite-devel mailing list
Sisuite-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
