Re: Can we do away with release and changelog bumping?
Le vendredi 10 juillet 2020 à 14:59 +0200, Nicolas Mailhot a écrit :
> Le vendredi 10 juillet 2020 à 13:22 +0200, Pavel Raiskup a écrit :
> > On Wednesday, July 8, 2020 6:25:57 PM CEST Nicolas Mailhot via
> > devel
> > wrote:
> > > Le 2020-07-08 17:19, Pavel Raiskup a écrit :
> > >
> > > > Small experiment (few-liner) for copr with "%bid, build system
> > > > tag":
> > > > https://pagure.io/copr/copr/pull-request/1436
> > >
> > > Well, that ties the system to corp, not koji
> >
> > The %bid macro is definitely meant to be usable with any build
> > system,
>
> That won’t work unless you persist the %bid state so the next build
> systems knows where to pick up from. And persisting is the part you
> do
> not like in my proposal (unless I completely misunderstood what you
> wrote before).
>
> Making things work across build systems without persisting means
> using
> an external reference like the clock, and that only works if your
> build
> history is completely linear, without scratched branches (intended
> scratch branches or branches that do not work out, despite the
> packager initial hopes)
Also, if you do not persist, your build won’t be reproducible in a
third party buildd system, because reproducing requires knowing the
%{bid} value you used in your own build.
--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
Le vendredi 10 juillet 2020 à 13:22 +0200, Pavel Raiskup a écrit : > On Wednesday, July 8, 2020 6:25:57 PM CEST Nicolas Mailhot via devel > wrote: > > Le 2020-07-08 17:19, Pavel Raiskup a écrit : > > > > > Small experiment (few-liner) for copr with "%bid, build system > > > tag": > > > https://pagure.io/copr/copr/pull-request/1436 > > > > Well, that ties the system to corp, not koji > > The %bid macro is definitely meant to be usable with any build > system, That won’t work unless you persist the %bid state so the next build systems knows where to pick up from. And persisting is the part you do not like in my proposal (unless I completely misunderstood what you wrote before). Making things work across build systems without persisting means using an external reference like the clock, and that only works if your build history is completely linear, without scratched branches (intended scratch branches or branches that do not work out, despite the packager initial hopes) Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
On Wednesday, July 8, 2020 6:25:57 PM CEST Nicolas Mailhot via devel wrote: > Le 2020-07-08 17:19, Pavel Raiskup a écrit : > > > Small experiment (few-liner) for copr with "%bid, build system tag": > > https://pagure.io/copr/copr/pull-request/1436 > > Well, that ties the system to corp, not koji The %bid macro is definitely meant to be usable with any build system, but I'm proposing that as Copr patch both because it is very trivial for me now and it is simple to test it there without the risk it will hurt anyone's work-flow with Koji. We just can afford to do such experiments there. The worst case scenario in using such macro everywhere is that particular build-system doesn't care about it (keeps it undefined). Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
Le 2020-07-08 17:19, Pavel Raiskup a écrit : Small experiment (few-liner) for copr with "%bid, build system tag": https://pagure.io/copr/copr/pull-request/1436 Well, that ties the system to corp, not koji, and like the other proposal, that makes releases that do not import from one system to another (which definitely matters to me, because my packager workflow has rpmbuild, mock, copr and koji stages). I honestly do not see how you can bump safely, without providing the bumping code the "bump from that point" information. When you bump, you graft new release growth over an existing release tree. Stacking something blindly without looking upon where you stack it will work in a lot of cases, but will fail horribly in others. I like KISS but this KISS is too SS for my tastes. If linear history worked for a project the size of Fedora we’d be all still using CVS. The bumping code itself is not hard to write Serializing 'bump from here' in a format that can be reliably read later is also not hard (as long as you do not insist on expanding Release and trying to decompose it back at the next build). The hard part is moving 'bump from here' info between builds. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
On Wednesday, July 8, 2020 4:16:34 PM CEST Pavel Raiskup wrote:
> On Monday, July 6, 2020 10:19:31 AM CEST Adam Saleh wrote:
> > Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
> > problem few months ago.
> > It is a koji plugin as well as CLI tool that makes bumping the release
> > field and generating changelog problem of Koji,
> > instead of package-maintainer. Currently it sits deployed in staging koji,
> > so you can give it a test-drive :-)
> >
> > We hope we can return to it later this year, to have it deployed in prod
> > koji.
>
> +1 to what Florian proposes over rpmautospec, though. I think bumping the
> release flag is the bare minimal technical change that is needed (except that
> bodhi should pre-fill the description by diffs from %changelogs).
Small experiment (few-liner) for copr with "%bid, build system tag":
https://pagure.io/copr/copr/pull-request/1436
Pavel
> I before stated my opinion that I don't like the generated %changelog
> idea. Fedora git changelog and `rpm --changelog` are two different
> things. Mixing them up will bring more costs than savings (fixing
> mistakes in git commit messages retrospectively). Or in other extreme the
> ugly `rpm --changelog` output (people don't care they mistakenly provided
> broken git commit message).
>
> I think that it would be just enough to allow people to stop producing
> `rpm --changelog`s if they think that it so awful amount of work (both
> better than more expensive %changelog variant, or ugly variant). Let's
> allow packagers to specify something like:
>
> %changelog
> * there's no package metadata in changelog
>
> Or in the worst case, automatize:
>
> * there's no package metadata in changelog
> - check %_pkgdocdir/fedora-git-changelog file
>
> I'm not saying that we can not see every proposed approach in action as
> opt-in. But, IMVHO, we are wasting to much efforts time here that could
> be spent on our content served to our users instead (== I mean the overall
> %changelog quality).
>
> Pavel
>
> > [1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html
> >
> > On Mon, Jul 6, 2020 at 8:22 AM 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.
> > >
> > > > 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.
> > >
> > > The %dist tag is not recorded in the changelog by most packages, so the
> > > changelog does not need changing.
> > >
> > > Thanks,
> > > Florian
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > 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@lists.fedoraproject.org
> > >
> >
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
On Monday, July 6, 2020 10:19:31 AM CEST Adam Saleh wrote:
> Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
> problem few months ago.
> It is a koji plugin as well as CLI tool that makes bumping the release
> field and generating changelog problem of Koji,
> instead of package-maintainer. Currently it sits deployed in staging koji,
> so you can give it a test-drive :-)
>
> We hope we can return to it later this year, to have it deployed in prod
> koji.
+1 to what Florian proposes over rpmautospec, though. I think bumping the
release flag is the bare minimal technical change that is needed (except that
bodhi should pre-fill the description by diffs from %changelogs).
I before stated my opinion that I don't like the generated %changelog
idea. Fedora git changelog and `rpm --changelog` are two different
things. Mixing them up will bring more costs than savings (fixing
mistakes in git commit messages retrospectively). Or in other extreme the
ugly `rpm --changelog` output (people don't care they mistakenly provided
broken git commit message).
I think that it would be just enough to allow people to stop producing
`rpm --changelog`s if they think that it so awful amount of work (both
better than more expensive %changelog variant, or ugly variant). Let's
allow packagers to specify something like:
%changelog
* there's no package metadata in changelog
Or in the worst case, automatize:
* there's no package metadata in changelog
- check %_pkgdocdir/fedora-git-changelog file
I'm not saying that we can not see every proposed approach in action as
opt-in. But, IMVHO, we are wasting to much efforts time here that could
be spent on our content served to our users instead (== I mean the overall
%changelog quality).
Pavel
> [1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html
>
> On Mon, Jul 6, 2020 at 8:22 AM 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.
> >
> > > 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.
> >
> > The %dist tag is not recorded in the changelog by most packages, so the
> > changelog does not need changing.
> >
> > Thanks,
> > Florian
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 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@lists.fedoraproject.org
> >
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
Adam Saleh wrote: > Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this > problem few months ago. > It is a koji plugin as well as CLI tool that makes bumping the release > field and generating changelog problem of Koji, > instead of package-maintainer. Currently it sits deployed in staging koji, > so you can give it a test-drive :-) What will the release value be when a package that uses autorel is built with fedpkg local? Or fedpkg mockbuild? Björn Persson pgpbSFrl37n3U.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
On 7/6/20 8:27 AM, Björn Persson wrote:
> 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}
fwiw, I've just been cobbling together a couple of specs with date tagging for
version mgmt between repos.
once I was pleasantly reminded to double-%% the date formats inside specs, it's
complicated only a bit by the occasional need to redefine %dist after multiple
forgemeta pulls.
otherwise, it's really handy.
currently this, e.g., works nicely 4 me:
https://download.copr.fedorainfracloud.org/results/pgfed/nginx-mainline/fedora-32-x86_64/01518639-nginx/nginx.spec
for my workflow,
-- get it working locally with rpmbuild
-- prove it works and is a properly closed build env in mock, locally
-- move local mock result into a local repo
-- push spec/srpm to COPR for build
I can effectively manage 'same' pkg+version, with builds differentiated by time
stamps. (for me, 1 sec min time slice is certainly good enuf!)
entirely possible that my 'kludge' hits an example of "a bit iffy"; hasn't
quite yet, tho ...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
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
pgpTBEyG2fROW.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
Le lundi 06 juillet 2020 à 13:06 +0200, Nicolas Mailhot a écrit : > > Because the build state exists in koji only, there is no need to > commit back to git. BTW I’m fairly certain I could have managed to implement the thing without adding source files to the SRPM, removing the need for mock changes of for back commits. It would have involved creating a separate subpackage for the state payload (à la debuginfo) with past state floating in this subpackage without ever being commited back. Much like the koji implementation makes changelog and release state float in a koji alternate dimension that is not Fedora git or the package sources. I decided against it because that would have made importing from one buildsystem to another quite inconvenient, and because it would have added a lot of (brittle) implementation complexity. These days my coding is very data-model driven, the right data model means a smaller and more future-proof implementation, the fact the autobump implementation is such a small diff shows the data model is right, IMHO Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
Le lundi 06 juillet 2020 à 10:19 +0200, Adam Saleh a écrit : > Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve > this problem few months ago. > It is a koji plugin as well as CLI tool that makes bumping the > release field and generating changelog problem of Koji, > instead of package-maintainer. Currently it sits deployed in staging > koji, so you can give it a test-drive :-) > > We hope we can return to it later this year, to have it deployed in > prod koji. > > [1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html I think it is good to have alternative implementations that show what the real consequences and costs of doing something one way or another are. The abovementioned implementation is tied to koji and will never work outside koji, and involves quite a lot of spec munging (that may work or not, I suspect it won’t work so well on my spec files for example). And it takes a lot of moving pieces to do so. Because the build state exists in koji only, there is no need to commit back to git. Conversely, this is what makes it a koji-only solution that does not export well to other build systems. My implementation is much simpler (6 files changed. 179 lines added. 5 lines removed) https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump However it relies on another redhat-rpm-config change which is definitely not simple (30 files changed. 2163 lines added. 619 lines removed). Though probably still quite less than the whole of rpmautospec + rpmautospec macros + koji plugin https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/213995c8371837f3689c0d053ed055c25de287c9?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump The other redhat-rpm-config change was done for other reasons, and contains code to address totally different needs, and I will need it whether the bumping change is done or not (but, I’m sure the rpmautospec guys will state a lot of their code was also written for other reasons). I suspect my implementation wins on genericity and on the other features it unlocks within spec files, while the rpmautospec implementation wins if you want to keep things within a little team of Fedora infra people. I’d call my implementation more elegant, because it tries to fix things within spec files first, and uses the fixes to make it easier to implement higher level features. While the rpmautospec solutions tries to take spec files as they are and force a high level feature over and from outside a packager spec file. But I will be the first to admit I am biaised. Had I not been convinced it was the right approach, I would not have invested the coding time in the first place. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Le dimanche 05 juillet 2020 à 23:36 +0200, Dan Čermák a écrit : > Nicolas Mailhot via devel writes: > > > Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : > > > Nicolas Mailhot via devel wrote: > > > > So if you want to push Fedora release logic to its ultimate > > > > conclusion, > > > > the thing that should be in charge of committing the new > > > > release/changelog build state to package history in git is > > > > bodhi, > > > > not > > > > koji. > > > > > > Why do build events need to be recorded in the Git history in the > > > first place? > > > > The changelog is built-in the rpm format. Therefore, it needs to > > exists > > at rpmbuild stage. Therefore, you need to record past changelog > > state > > so new builds are consistent with previous builds. > > The changelog should be consistent, but it needn't record every > single > build event. Otherwise OBS would not work at all: the build system > bumps > the release field automatically on each rebuild, but it does not > touch the changelog at all. Well just bumping the changelog by default, and letting the packager remove unecessary lines when he has the time to look at the changelog, is a much friendlier workflow than asking the packager to think about it on every single build, redoing builds when he forgot about it because redoing builds is the only way to get a new changelog included in the binary payload. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
problem few months ago.
It is a koji plugin as well as CLI tool that makes bumping the release
field and generating changelog problem of Koji,
instead of package-maintainer. Currently it sits deployed in staging koji,
so you can give it a test-drive :-)
We hope we can return to it later this year, to have it deployed in prod
koji.
[1] https://docs.pagure.org/Fedora-Infra.rpmautospec/principle.html
On Mon, Jul 6, 2020 at 8:22 AM 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.
>
> > 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.
>
> The %dist tag is not recorded in the changelog by most packages, so the
> changelog does not need changing.
>
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
* Björn Persson:
> The macro could be defined like this for example:
>
> %buildtag .%(date +%%s)
Using time for synchronization is always a bit iffy.
> 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.
The %dist tag is not recorded in the changelog by most packages, so the
changelog does not need changing.
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping?
Nicolas Mailhot via devel wrote: > Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : > > It seems that several problems would just disappear if a rebuild > > would generate a unique package ID without a Git commit. > > That’s exacly what the change does. No it's not. Your key/value file must be updated in Git. Otherwise it won't remember previous release bumps. You seem to want to do the commit after building instead of before, but it's still a commit to Git that changes only the release number and the changelog. My idea is a way to *not* do that commit, neither before nor after building. Björn Persson pgp_iMlQVE_gO.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Nicolas Mailhot via devel writes: > Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : >> Nicolas Mailhot via devel wrote: >> > So if you want to push Fedora release logic to its ultimate >> > conclusion, >> > the thing that should be in charge of committing the new >> > release/changelog build state to package history in git is bodhi, >> > not >> > koji. >> >> Why do build events need to be recorded in the Git history in the >> first place? > > The changelog is built-in the rpm format. Therefore, it needs to exists > at rpmbuild stage. Therefore, you need to record past changelog state > so new builds are consistent with previous builds. The changelog should be consistent, but it needn't record every single build event. Otherwise OBS would not work at all: the build system bumps the release field automatically on each rebuild, but it does not touch the changelog at all. Cheers, Dan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Le dimanche 05 juillet 2020 à 18:41 +0200, Nicolas Mailhot a écrit : > > While timestamping would remove the need to pass the last build info > to the next one it would also break all the workflows where several > rebuilds are done in parallel for separate needs, and the latest > rebuild is not necessarily the one you want to keep. (This is why git is not relying on timestamps to construct commit timelines, for example. A reliable timeline system knows what change occured before the next one.) -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit : > Nicolas Mailhot via devel wrote: > > So if you want to push Fedora release logic to its ultimate > > conclusion, > > the thing that should be in charge of committing the new > > release/changelog build state to package history in git is bodhi, > > not > > koji. > > Why do build events need to be recorded in the Git history in the > first place? The changelog is built-in the rpm format. Therefore, it needs to exists at rpmbuild stage. Therefore, you need to record past changelog state so new builds are consistent with previous builds. You may argue that the existence of scms like git makes built-in changelogs irrelevant. People that have to debug problems in systems that mix packages sources will disagree – they have no wish to comb multiple external scms to find what was changed in a package set that breaks (hard to do when the thing that broke is networking for example). And, even if you removed completely the changelog from the rpm format, you’d still need to manage package releases. > So why is NEVR required to change when nothing in the package source > has changed? The NEVR is required to change because you need to publish a new package ID to clients, so clients know they have an update to deploy. That has nothing to do with koji limitations, it’s a requirement or the rpm update system, or pretty much any change management system for that matter. > It seems that several problems would just disappear if a rebuild > would generate a unique package ID without a Git commit. That’s exacly what the change does. > Here's an idea: We could mandate that Release must expand a macro > called buildtag. This macro would have a new value every time, > monotonically increasing. A timestamp seems easiest, but that should > bean implementation detail that could be changed without breaking > things. Because things are slightly more complex than you think they are, the counter is not just a timestamp, and there are two not one counter, but yes, again, that’s exacly what the change does. > (The build time is already stored in packages, and could > theoretically be used to tell builds apart, but that would require > changes to lots of tools I guess.) The build time by itself is not sufficient because you have branches, and scratch builds (which are basically abandonware branches) so parallel package history exists and a single monotonic timeline can not represent that. Nevertheless the last build time is useful (for changelog bumping, if nothing else) and is one of the things the change stores as past state (you could try to deduce it from other things, but why bother, a timestamp variable is cheap and easy to manipulate). > Mass rebuilds would no longer make any Git commits. They would just > take the latest version and submit it for building. Again, that’s basically what the change does. A build stores counters and date as they existed as the time of the build in one of the SRPM source files. The next build reads this file and computes a higher release. No external bump script involved. No spec file change required. The spec file can be left unchanged forever, the release info in there is just the last release someone made a change to the spec files, and everything autobumps from there. All you need is to pass the "last build" info from one build to another, which is done via importing the results of last build at the start of the new build. Since the import relies on SRPM content and nothing else you can even move the build chain from one buildsystem to another it will still work. While timestamping would remove the need to pass the last build info to the next one it would also break all the workflows where several rebuilds are done in parallel for separate needs, and the latest rebuild is not necessarily the one you want to keep. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)
Nicolas Mailhot via devel wrote:
> So if you want to push Fedora release logic to its ultimate conclusion,
> the thing that should be in charge of committing the new
> release/changelog build state to package history in git is bodhi, not
> koji.
Why do build events need to be recorded in the Git history in the first
place? A version control system is supposed to track changes to the
source code. A rebuild that doesn't change any sources, patches,
scriptlets or metadata shouldn't need to change anything in Git.
As far as I can tell, this happens only because Koji refuses to build a
NEVR that has been built before, so a rebuild requires a new release
number, which requires an RPM changelog entry, and both of those are
defined in the spec, which is stored in Git.
So why is NEVR required to change when nothing in the package source
has changed? Apparently because *other* packages are likely to have
changed: new versions of libraries, compiler et cetera causing
differences in the generated code. That's the usual reason for rebuilds
after all. But if one takes a source package and rebuilds it locally,
then one won't have the same version of every other package, so one
gets another binary package with the same NEVR but probably different
binary code.
It seems that several problems would just disappear if a rebuild would
generate a unique package ID without a Git commit. Instead of a lot of
complex tooling to automate release and changelog bumping, I would like
to see the need for release and changelog bumping go away.
Here's an idea: We could mandate that Release must expand a macro
called buildtag. This macro would have a new value every time,
monotonically increasing. A timestamp seems easiest, but that should be
an implementation detail that could be changed without breaking things.
The macro could be defined like this for example:
%buildtag .%(date +%%s)
It would be used in each spec like this:
Release: 1%{?dist}%{?buildtag}
Putting the buildtag after the disttag makes it possible to change how
the buildtag is generated in a future Fedora release without breaking
upgrade paths.
(The build time is already stored in packages, and could theoretically
be used to tell builds apart, but that would require changes to lots of
tools I guess.)
Mass rebuilds would no longer make any Git commits. They would just
take the latest version and submit it for building. The release number
would remain as a downstream version number. Packagers would update the
release number when they make actual changes to the package. When one
wants a specific version of a package, one would look at the version
and release numbers, ignoring the buildtag. The buildtag would
distinguish between different builds of the same version-release.
What flaws can you all find in this idea?
Björn Persson
pgpIGk2i3K6iH.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
