Florian Weimer wrote:
> * Björn Persson:
>
> > The macro could be defined like this for example:
> >
> > %buildtag .%(date +%%s)
>
> Using time for synchronization is always a bit iffy.
Well, if somebody manages to build a package twice within a second,
using two different versions of a compiler ... then they still won't be
any worse off than they are today. Koji should still not allow it.
> > It would be used in each spec like this:
> >
> > Release: 1%{?dist}%{?buildtag}
>
> We could put the Koji task ID directly into the %dist tag. We know that
> this works in principle. If we are worried that the number gets too
> large, we could subtract the current task ID at the time the fcNN part
> of the %dist tag changes.
That could also work. Locally rebuilt packages would of course lack the
task ID, so they would compare as less than the official package. Is
that desirable? It could work as an incentive for the user to add some
local tag to the release value, making it clearer that the package has
been modified locally.
Or would we want to modify the disttag so that locally rebuilt packages
would compare as greater than the corresponding official package? Then
Yum would replace the official package with the rebuilt one, but would
still install an official update with a greater release number.
Björn Persson
Attachment:
pgpMQa42RZkeu.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
