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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
