Re: What is the real value of Release and %changelog metadata?

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

 



Pierre-Yves Chibon wrote:
> On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> > Let's stop requiring Release bumps for each build.  And let's put an
> > additional tag into Release, like proposed in [4]:
> > 
> >     "Release: 1%{?dist}%{?buildtag}"
> > 
> > ... and let the build-system to put there an artificial (but increasing for
> > subsequent build IDs) value.  
> 
> When looking into rpmautospec this was one of the idea we thought about. There
> are a few downsides to it that made us go in a different direction:
> 
> - Relies on the build system and cannot be emulated locally (without access to
>   it)

Using timestamps for buildtags would work across build systems, relying
only on the clock not being wildly off.

Using Copr build IDs and Koji task IDs, each build system would have
its own series of buildtags. Local Mock and plain RPMbuild could have
their own series too, using timestamps or something else.

The feature that was recently added to Copr generates buildtags that
begin with ".copr". Buildtags from Koji could begin with ".koji". These
prefixes could be chosen so that a build from Koji takes priority over
one from Copr, and a local build takes priority over both of those. I
notice that "local" > "koji" > "copr". How convenient. (A package being
moved from Fedora to Copr would then need a manual release bump, but I
can't think of a reason to do that if there's neither a new version nor
any change to the packaging.)

> - Conflicts wit the minor release bump field of the versioning schema:
>   https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_more_complex_versioning

I think I see what you mean. If buildtags are purely numeric, then
inserting a small numeric minorbump before the buildtag where the field
was previously empty would cause the new build to compare as less than
the previous one:

$ rpmdev-vercmp 1-1.fc33.98765 1-1.fc33.1.98789
1-1.fc33.98765 > 1-1.fc33.1.98789

If, on the other hand, buildtags begin with a letter and minorbumps are
numeric, then a build with a minorbump would compare as greater:

$ rpmdev-vercmp 1-1.fc33.koji98765 1-1.fc33.1.koji98789
1-1.fc33.koji98765 < 1-1.fc33.1.koji98789

Another option is to have the minorbump field always present, with the
value 0 when not in use. Yet another option is to put the minorbump
after the buildtag. I'd say this is technically manageable, but there
is some risk that packagers would do minorbumps wrong by mistake.

Björn Persson

Attachment: pgps3uvhlvo3Z.pgp
Description: OpenPGP digital signatur

_______________________________________________
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