Hi,
My "OSTree" system which I'd like to deploy in Fedora treats operating system binaries like git treats source code - they have a versioned history. This is in contrast to the default mode of operation with RPM and higher level systems like Koji which will garbage collect older binaries that are not part of a release.
This rpm-ostree is not a new source-level build system - merely a new representation of the binary RPMs.
Now, I want this system to be compliant with both the letter and spirit of the GPL - you should be able to find the source for a given binary that's included in the OSTree repository.
My understanding is that normally with yum/rpm as they are today, "rpm -qf /usr/bin/bash" telling you the binary came from the bash package, and then "rpm -qi bash" showing you the source RPM name, then finally locating the bash-$version.src.rpm provided from e.g. http://koji.fedoraproject.org/koji/buildinfo?buildID=482681 is sufficient.
With OSTree, I may not even include rpm inside the composed tree (the system shipped to users) - in that case, I include the output of "rpm -qa". While the file -> package mapping is not included in this model, the source is available and provided by Fedora.
So that's my first question - do I need to include the file-level mapping so one can go from binary -> package -> source package?
Second, Koji may garbage collect the RPMs and SRPMs, for an obsoleted build, but rpm-ostree may retain the binaries.
Is the package git sufficient for this purpose? One can reconstruct the SRPMs from that. Or would we need integration between Koji and rpm-ostree to avoid having SRPMs garbage collected as long as they're stored in the OSTree repository?
Thanks in advance for any advice or help!
On 02/19/2014 12:58 PM, Colin Walters wrote:
So that's my first question - do I need to include the file-level mapping so one can go from binary -> package -> source package?
I think so, but read on.
Second, Koji may garbage collect the RPMs and SRPMs, for an obsoleted build, but rpm-ostree may retain the binaries.
Is the package git sufficient for this purpose? One can reconstruct the SRPMs from that. Or would we need integration between Koji and rpm-ostree to avoid having SRPMs garbage collected as long as they're stored in the OSTree repository?
The latter is preferred, but I think the former would be sufficient if it is technically infeasible.
The rule of thumb is that if you distribute binaries, you need to have an obvious pointer to the source. We assume people who have our RPMs will be able to find the matching SRPMs (either from the download trees, or from the repositories, or koji), so os-tree needs to have a similar arrangement. Even a generated SOURCES.txt that tells the user which koki/git commands to run to get the matching source would be sufficient.
hth,
~tom
== ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸><(((º> OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal
On Wed, Feb 19, 2014 at 2:09 PM, Tom Callaway tcallawa@redhat.com wrote:
On 02/19/2014 12:58 PM, Colin Walters wrote:
So that's my first question - do I need to include the file-level mapping so one can go from binary -> package -> source package?
I think so, but read on.
Ok, at the moment https://bugzilla.redhat.com/show_bug.cgi?id=1062328 forces rpm to be installed anyways...and I think for now I just won't try to support making trees without rpm inside them.
The latter is preferred, but I think the former would be sufficient if it is technically infeasible.
Ok. It's *feasible* I'd say, but just a lot nicer to not have to worry about SRPMs explicitly. They made sense as a source format *before* revision control...
Let's focus on this question then of SRPMs versus pkg git.
It seems to me that if koji retains the metadata that one can see here: http://koji.fedoraproject.org/koji/taskinfo?taskID=6448116 which ties a particular built ENVR -> pkg git commit, that is enough to act as a source link. I just need to be sure that metadata is retained over the long term.
But at this point this is probably more of a discussion to have with the Koji side of things then.
Over the years I've seen several employers not archive object code, binary packages, etc. based on thinking that they can always be recreated from a saved source tarball, or source control. That has almost always been a mistake, as by the time there was some need to recreate it, the tools had changed enough that it was actually quite difficult, even if the tools are also in source control.
The archival needs to comply with the GPL are different than the archival needs of a commercial (non-GPL) vendor, so the described problem isn't as relevant, but IMHO it's worthwhile to save the SRPMs and binary RPMs of released packages (including released updates), but not other koji builds.
Eric
-
Colin Walters -
Eric Smith -
Tom Callaway