Openmoko build infrastructure questions

Andy Green andy at
Wed Apr 16 19:46:27 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

|> SRPMs are great and I am sure Debian source packages the same.  If you
|> actually have to ship binaries for GPL code, SRPM that guarantees to
|> capture all sources and build scripts in one file is a beautiful sight.
|> ~ Doesn't matter they are hard to work with, your license issue is
|> solved.
| Come on. That is a non-issue. This has nothing to do how good srpm does
| a job or how much fun it is to use it.

Wah.  It's a big issue to capture all sources in a project and offer
them in compliance with GPL.  Every build you make, even if for a bugfix
test -- it's your job to pony up the sources if you gave a binary.
Source packages resolve this in a clean way.

| It guarantees just nothing. You could throw non compliant code in a srpm
| as much as you could commit it in the source dir of any bitbake package.

Tilman I read this part by holding my laptop up to a mirror to fool my
head explosion protection, some blood came out of one ear, but otherwise
I am OK.  After that I lay down for a bit and didn't dare read the rest.

Source packages typically contain an upstream tarball, a patchset and
the spec file used to control the build.  In fact everything to make the
binary except the build tools like compiler.  Yes you can mess it up,
but typically you don't mess it up and the source package is everything
you needed to regenerate the binary, created at the time the binary was
created.  To the point you can delete your build tree of it and the SRPM
is your "compressed backup".  It's as good as an insurance you can get
against license violation and capability to "give what you used".

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the distro-devel mailing list