Re: [Fedora-packaging] Re: Ideas and proposal for removing changelog and release fields from spec file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux