On Sun, 2006-09-17 at 09:19 +0200, Axel Thimm wrote:
On Sun, Sep 17, 2006 at 07:53:10AM +0200, Ralf Corsepius wrote:
> On Sat, 2006-09-16 at 22:08 -0700, Toshio Kuratomi wrote:
> > Hey guys,
> > It's come to my attention that we don't have a "Packages must be
built
> > from source, no precompiled binaries" rule in the current guidelines. I
> > think this is an oversight as the Binary Firmware section:
> >
http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware
> >
> > implies this for the specific case of firmware.
> >
> > How about something like:
> >
> > "Packages must be built from source code. Including pre-built programs
> > or libraries is strictly forbidden. A select few exceptions are made
> > for binary firmware. Please see
> >
http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware
> > for details."
> >
> > And on ReviewGuidelines:
> > "Must: The package must be built from source. No pre-built programs or
> > libraries are acceptable."
> -1
>
> > Thoughts, opinions welcome.
>
> IMO, both rules above are a mistake.
>
> In my understanding the original intend was to force "rebuildability" on
> LINUX code, i.e. all Linux code to be open-sourced.
>
> I.e. you'd first have to define what you understand as "Linux code".
>
> A native firmware to be applied by a running Linux kernel would
> definitely qualify as such. But a firmware (as being applied by
> emulators) or foreign libraries (as being required by cross compilers)
> are cornercases.
>
> I find forcing to build them from source to be non-helpful, because
>
> 1. Technically,
> - Rebuilding such binaries can require very large toolchains underneath.
>
> - The toolchains required to rebuild such binaries, often have a
> circular dependency on such binaries. E.g. bootstrapping
> (cross-)compilers from scratch often is not possible or at least very
> hard to achieve (Applies to Linux itself, too)
>
> - Forcing to rebuild a binary introduces a very large risk of producing
> a non-usable binary from it, due to bugs in the toolchain required to
> rebuild it. Fixing such bugs is far from being trivial.
Doesn't all this apply to several other software projects like gcc and
openoffice, too?
Dunno about openoffice, but this applies a GCC/kernel/glibc
triple.
To build them from scratch, you at one point need a foreign OS and a
foreign c-compiler.
Why, then, do we ship source for these, too?
Strictly
speaking, we don't: GCC/kernel/glibc being built incrementally.
We don't ship the foreign OS and the foreign c-compiler, you'd need to
build them from scratch.
> 2. Where to draw the line between "such binaries" and
"ordinary data"?
>
> >From a running OS's perspective, running a "non-native firmware"
on in
> am emulator is not any different from processing "data", e.g. displaying
> a postscript document in ghostscript is essentially the same as running
> a foreign firmware in an emulator.
So uploading closed source binaries to arm/scalepath/ppc hardware from
i386 should be allowed?
No, closed-source != binary.
The question is whether we enforce "must rebuild everything from scratch".
IMHO I think our mission as the packaging group is that need to
define
*how* to package something. *Whether* something is allowed to be
packaged or not is not our decision. See also the kernel module
discussion.
Agreed.
Ralf