On Tue, 3 Mar 2020 at 09:38, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > > Le 2020-03-03 07:03, clime a écrit : > > > Actually, that wouldn't work because prefix needs to be static, not > > dependent on rpm macros > > For myself, I would oppose any rpm release process that would not take > core rpm mecanisms like macros into account. Being independent of rpm has one huge potential advantage. You can apply the same approach that you apply for rpm spec files to other kinds of spec files. For example the fedora & containers mailing list contains a thread, when person needs to parametrize FROM clause by branch name to correctly reference base image: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/65GHZM4PODSO36C66ONZCYXVIN7JIXMK/ The approach I am suggesting would help there and it could help on other places too. > > Recording builds in changelogs without checking they actually happened > is bad engineering. It's not about recording builds but instead about recording releases which I see as something that takes place already in Git. > > Simulating rpm behaviour without performing actual spec evaluation in > rpm, is also bad engineering. Especially when you know your simulation > is horribly simplistic and approximative. I am not trying to simulate rpm behavior. I am just trying to introduce macros that are rendered verbatim into the spec file inside srpm so those srpms can be rebuilt at any time when needed. rpm does not have this feature atm. If we should put it into rpm, it would be already third kind of rpm macro but even if it should go into rpm at some point, it is better to have the approach heavily tested by production use first because here it doesn't really add much complexity. And as I mentioned, independence of rpm means you can use it for non-rpm projects too. It's also not simplistic: what you see in {{{ }}} tags is interpreted by bash, it can be multi-line and you can hence do anything there you can do with rpm macros. The only problem is, people already have some automation in rpm macros that doesn't require the git context, instead just e.g. the tarball content and this functionality would need to be rewritten by using {{{ }}} if it should play together with the git-based release generation. This cannot be avoided as much as I would like to. If we try to avoid it, we will get a weird hybrid that doesn't work. It's also not approximative. You can define your own logic for generating release. There should be some pre-made recommended macros but in the end you are not limited by them. > > “Who cares if results match most of the time” is terrible workload > optimization. You’ll make packagers waste far more time fixing the cases > where automation guessed wrong, than you will win when it guesses right. > Basic 80/20 rule, the 20% hard cases cost more than the 80% easy cases. > Taking care of the 80% easy cases while making the 20% hard cases harder > (due to automation mistakes) is not a good deal at all. > > Please work on approaches which are reliable by default. Reliability is > hard even when you aim for it. When you don’t, it’s not attainable at > all. I think the approach I am suggesting is very reliable. As much as I enjoy this conversation, I will need to actually try to make something happen. Forgive me if I don't go into long disputes hereafter. If you, however, make a detailed document summarizing the infra changes needed for your approach I will try to comment on the individual aspects of it and also respond with the document with the changes needed for what I am suggesting. Best regards! clime > > Reagrds, > > -- > Nicolas Mailhot > _______________________________________________ > packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
