Texlive packaging

[Miloslav Trmač]

Hello,
> On Fri, Mar 27, 2015 at 08:28:21PM +0100, drago01 wrote:
> > Actually "machine generated" isn't per se bad  ... it saves a lot of
> > effort and should be done more (for other packages too where
> > possible).
> > Why waste man power for something that can be automated?
> > 
> > As for tex ... we could have a srpm for each one (machine generated
> > there is no reason it has to be one srpm) would also mean that only
> > the packages where something changes end up getting updated.
> 
> Right, as I understand it, the gigantic single SRPM is to avoid the
> normal requirement that each individual package have its own manual
> review. For thousands of packages, that's quite a burden.
> 
> But the workaround, while not violating any specific guidelines,
> doesn't _really_ have any more careful individual review of each of its
> parts — it's not a gain. And it has negative side-effects.
> 
> If FPC would be open to bulk-approving machine-generated individual
> spec files (given, say, they're provably all following the template,
> which would be reviewed), and rel-eng has some way of bulk-adding the
> necessary branches and builds, that really seems like a step forward to
> me.
> 
> Am I missing something?

It is a general best practice to store the “actual source” (~preferred for of modification) in a versioning system, and not the generated results, e.g. to avoid manual edits to the generated files being lost on next regeneration.  The current texlive texlive git repo does contain the generated texlive spec file, but it is IMHO much closer to the ideal than having thousands of individual repos with autogenerated spec files—either not having the template and generating tool in the git repo at all, pretty much guaranteeing drift from manual edits, or having a copy of the template and generating tool in each of the repos, making it very likely that the the template and tool will go out of sync.

Ideally we would want the autogenerating tool in in a repo shared for all the packages (or perhaps just in a package required by redhat-rpm-config?), and then have no texlive*.spec files in git at all; this seems unlikely to happen soon.  Failing this, the current arrangement seems by far the most maintainable alternative.
    Mirek