On 03/07/2018 04:46 AM, Florian Weimer wrote:
On 07/07/2017 11:04 PM, Florian Weimer wrote:
> Would it concern you if the source RPM size grew to about 110 MiB?
It would not concern me.
> This data would not have to be uploaded with a “fedpkg
> new-sources” command for every upstream import, only once per
> Fedora release cycle.
OK.
I don't think anyone has replied to this question so far.
I must have missed this, sorry, or I would have responded.
What really matters to our users is the size of the binary rpms, and
so things like locale-archive growing +80MiB is a more serious issue,
but we thankfully can combat that easily because we have split the
language packs and glibc-all-langpacks is the only thing that grew,
not the default glibc package.
We can probably bring it down a bit (to ~95 MiB or thereabouts), but
it obviously will grow again.
The background of my question is whether we can ship the entire
upstream Git history in the SRPM, and add a Git bundle on top of that
with the Fedora changes (which can contain merges from the upstream
release branch, among other things). There would not be any patch
files anymore, just a baseline bundle (unchanged after the upstream
release) and an updates bundle.
Is your idea to have a stand-alone SRPM that can be self-hosting
e.g. generate it's own files without external tooling?
I encourage this kind of self-sufficient hosting of the SRPM, any
non-self-hosting makes things harder for us and users.
The alternative is that we have external tooling in glibc-maintainer-scripts
which takes as input all of the source trees (in git) we need to
regenerate the tree right?
There would have to be a tool to create the updates bundle from the
original (non-dist-git) Git repository. It would also extract the
glibc.spec file from the source Git repository and synthesize a
Release: entry and a bit of %changelog contents (listing only those
commits since the last manual %changelog update in the committed
glibc.spec file).
Sounds great!
This is peripherally related to Carlos' ABI checking efforts.
Once
we follow that model, we could simply put the ABI definitions as
plain XML files in a subdirectory in the non-dist-git repository.
Changes to the ABI definitions could be reviewed along other changes
to it.
Would we create an upstream Fedora branch that is based on the
glibc release, and then layer the ABI baselines there?
Then we would work directly on the upstream Fedora branch? Sounds great.
--
Cheers,
Carlos.