comments inline
On Wed, Apr 14, 2021 at 4:09 PM Daniel P. Berrangé <berrange(a)redhat.com> wrote:
On Wed, Apr 14, 2021 at 10:45:23AM +0200, Tomas Tomecek wrote:
> Good morning, I'd like to announce the creation of Fedora Source-git SIG:
>
>
https://fedoraproject.org/wiki/SIGs/Source-git
>
> Our main goal in the SIG right now is to establish a development
> workflow for Fedora Linux packages using repositories with sources and
> upstream history (this is what we call source-git), instead of just
> distribution files with links to tarballs (dist-git).
>
> Please head to the SIG wiki page to learn more about our proposed MVP.
> We are looking for maintainers of Fedora Linux packages who'd be
> interested in being early adopters and give us feedback during the
> development process. You don't need to do any coding unless you want
> to :)
We might be interested in trialling it with some of the virt packages.
I'm wondering about the scope of this statement from the wiki page
above:
"Whatever we produce here, it MUST NOT violate Fedora Packaging
Guidelines (we should strive to change them if needed)."
I can certainly understand the intent behind this when dealing with
legally restricted content. eg don't allow impls of patented algorithms
that are blocked from dist-git.
In terms of scope I can reasonably audit the source for current git
master or a specific git tag to ensure legal compliance.
I can't reasonably audit the entire source-git history of the project
back to day 1 though, to make sure the git repo has never had legally
restricted content at any point in the past 20 years of its life.
IOW, I'd hope that in terms of FPG compliance, we only need to consider
the specific tag/branch that's being used to populate dist-git and can
ignore history.
This could still potentially mean that source-git is a complication for
the packages where we have to re-create the tarballs after removing
patented crypto. Will legal allow it to remain in source git, but
require it to be purged when src-git syncs to dist-git or something
like that ?
Overall this does seem to imply though that if Fedora hosts src-git
repos with upstream history itself, then it is potentially opening
a new liability that it hasn't had before. If we're going to host
src-git on a Fedora namespace on
gitlab.com though, then its someone
else's problem to worry about, and Fedora only needs to worry about
what's synced to dist-git for the actual RPMs builds.
Thank you, Daniel, very good points! I'll add this to the agenda of
the first meeting to bring this to Fedora Legal. I also hope to make
the legal aspect of this someone else's problem - on the other hand,
if this workflow ever gets approved by FESCO and become official
(aside from the dist-git workflow) the repos would need to be hosted
on Fedora Infra.
Aside from legal, I also wonder about things like binary blobs or
bundled libraries. These are relatively common to see in upstream
git repos, even if they don't make it into the release tarballs that
Fedora traditionally consumes.
Hopefully the requirement to comply with Fedora Pakaging Guidelines
will only apply to files in src-git that actually get used for
Fedora builds, and not stuff that exists but is skipped/ignored ?
Yes, I'd say to files which are being put to dist-git and used for
official builds. Short term, I don't think it's feasible to create
production koji builds out of these source-git repositories. That
would be the long term plan :)