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 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
