De: "Colin Walters"
I appreciate the work you're doing here,
Thank you
but I think the right path for golang (indeed for most other language
ecosystems) is to autogenerate
specs.
You're, of course, are entitled to your opinion, but I do not share it :) I think rpm
has been an incredibly successful technology. It is used today to package software no one
could imagine when rpm was designed, in languages that didn't even exist at that time,
and yet one can open spec files from last millenium and still recognize most of the
parts.
And during all that time, people have been writing one spec generator after another, that
all failed to get serious traction, and make any serious impact.
I think that the reason for rpm success on one hand, and the serial flops of spec
generators on the other, it that spec generators are inherently inflexible. They do not
deal well with special cases. They do not deal well with mixed projects that require
combining several packaging patterns. They are very slow to adapt to rpm enhancements.
It's so easy to generate yet another line of code there is no incentive to refactor
what's generated to remove parts no longer needed, to strive for succinctness,
efficiency and maintainability.
By and large generators generate very verbose low-quality spec code, which can of course,
be manually adapted, but is not designed to be adapted by humans, making adaptations hard
and inefficient (that seems to be a common pitfall of code generators of any sort). And,
when packaging any large pool of software, you will hit many special cases, because
software is written by humans, humans are messy, and expecting every software project to
follow conventions with the level of strictness expected by spec generators is, IMHO
illusory.
spec file syntax, warts and all, seems to hit the sweet spot between the wish to automate
as much as possible, and the need to add a few lines of custom code whenever a project
needs a little dose of custom handling.
I could, quite easily I think, implement something similar to autospec for Fedora Go
packages. All it would take would be to define a variable name for each parameter of the
autospec manifest, then call a giant macro that generates the rest of the spec file. I
didn't do it not because I don't know how to, nor because it wouldn't work as
is for many Go projects, but because it would suffer from the usual generator
inflexibility, and inability to handle special cases, and projects that deviate slightly
from the norm. I *chose* to split the Go automation in separate rpm macros, that can be
combined by packagers as needed in different ways, that can be mixed with the other macros
implemented by Fedora, that can be completed by custom spec code when there is a need
(that is BTW a balance I didn't get quite right when I automated fonts packaging a few
years ago, with hindsight I wish I had designed something a little more adaptable, with
more flexibility).
Basically I feel that providing powerful spec verbs, is a more powerful model than
expecting to capture every need in rigid autogenerated templates, no matter the amount of
switches bolted on later, to manage all the deviations not envisioned when defining the
original "simple" generation.
That being said rpm is not perfect and will need to continue to evolve to stay relevant.
For example, with the horizontal compilation model of Go, the number of BuildRequires in
specs is getting out of hand. So rpm and mock will probably need to evolve towards a
model, where BuildRequires are not frozen till the end of %prep. That would allow to infer
at least some BuildRequires from what's in the project archive, instead of requiring
packagers to declare every single BuildRequires manually, because the build root is setup
before the archive is even opened. However I see such things more like a natural evolution
of the rpm model, and certainly nothing that requires dumping rpm, or "fixing"
it with a generation layer.
Also having all of the golang -devel packages in a single git
repository
with subdirectories so it's easy to have a single PR affect multiple packages
at once.
I can't really disagree there, that's how we work internally. It has proved
invaluable every time we hit "damn, that's the twentieth spec that needs this
exception, maybe it's time to fold it in common macro code to simplify those specs and
avoid writing the exception another time, let's refactors all this in a single commit
(or commit series)"
Regards,
--
Nicolas Mailhot