Hi, I've just realized that %dist is defined to:
%{?distprefix}.fc30%{?with_bootstrap:~bootstrap}
That effectively means that using %bcond_without bootstrap, the dist is changed to .fc31~bootstrap.
Is this something that we actually want? E.g. I was quite surprised by the behavior.
Reading https://pagure.io/packaging-committee/issue/818 gives me an impression that the packaging committee didn't really approve nor forbid this, so I'm looking for recommendation.
When I bootstrap, should I manually bump the release number or let this magic happen?
Also, how do I opt-out from this behavior (other than renaming my conditional)?
On Sun, Mar 10, 2019 at 6:13 PM Miro Hrončok mhroncok@redhat.com wrote:
Hi, I've just realized that %dist is defined to:
%{?distprefix}.fc30%{?with_bootstrap:~bootstrap}
That effectively means that using %bcond_without bootstrap, the dist is changed to .fc31~bootstrap.
Is this something that we actually want? E.g. I was quite surprised by the behavior.
Reading https://pagure.io/packaging-committee/issue/818 gives me an impression that the packaging committee didn't really approve nor forbid this, so I'm looking for recommendation.
When I bootstrap, should I manually bump the release number or let this magic happen?
Let the magic happen. Embrace it, and it will help you. 😁
Also, how do I opt-out from this behavior (other than renaming my conditional)?
I don't think you can unless you rename your conditional. This part was kinda added for Go things by Nicolas Mailhot. 🤷♂️
Dne 10. 03. 19 v 23:17 Neal Gompa napsal(a):
On Sun, Mar 10, 2019 at 6:13 PM Miro Hrončok mhroncok@redhat.com wrote:
Hi, I've just realized that %dist is defined to:
%{?distprefix}.fc30%{?with_bootstrap:~bootstrap}
That effectively means that using %bcond_without bootstrap, the dist is changed to .fc31~bootstrap.
This is the latest discussion about `%bcond_without bootstrap` as far as I remember (of course except the ticket bellow).
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
Is this something that we actually want? E.g. I was quite surprised by the behavior.
Reading https://pagure.io/packaging-committee/issue/818 gives me an impression that the packaging committee didn't really approve nor forbid this, so I'm looking for recommendation.
When I bootstrap, should I manually bump the release number or let this magic happen?
Let the magic happen. Embrace it, and it will help you. 😁
+1
V.
Also, how do I opt-out from this behavior (other than renaming my conditional)?
I don't think you can unless you rename your conditional. This part was kinda added for Go things by Nicolas Mailhot. 🤷♂️
Le 2019-03-10 23:17, Neal Gompa a écrit :
On Sun, Mar 10, 2019 at 6:13 PM Miro Hrončok mhroncok@redhat.com wrote:
Hi, I've just realized that %dist is defined to:
%{?distprefix}.fc30%{?with_bootstrap:~bootstrap}
That effectively means that using %bcond_without bootstrap, the dist is changed to .fc31~bootstrap.
Is this something that we actually want? E.g. I was quite surprised by the behavior.
Reading https://pagure.io/packaging-committee/issue/818 gives me an impression that the packaging committee didn't really approve nor forbid this, so I'm looking for recommendation.
When I bootstrap, should I manually bump the release number or let this magic happen?
Let the magic happen. Embrace it, and it will help you. 😁
Also, how do I opt-out from this behavior (other than renaming my conditional)?
I don't think you can unless you rename your conditional. This part was kinda added for Go things by Nicolas Mailhot. 🤷♂️
I plead not guilty, I'm responsible for the distprefix addition (for the forge macros, not just Go packages), not the bootstrap one :)
Many kuddos to the people who wrote the bootstrap part, more automation is always good.
Now, if I *had* written the bootstrap part, I would have packed it inside a distpostfix, to keep dist construction under packager contol.
Regards,
"MH" == Miro Hrončok mhroncok@redhat.com writes:
MH> Is this something that we actually want? E.g. I was quite surprised MH> by the behavior.
What about it is surprising? You remove the bootstrap bit and without changing anything else you have a package which sorts newer than the previous with-bootstrap package. Even though we haven't yet run short of integers, I can see the utility in this.
MH> When I bootstrap, should I manually bump the release number or let MH> this magic happen?
Well, obviously you have to bump it once. Whether there's any utility in saving you from having to bump twice is up for discussion, but certainly you can.
MH> Also, how do I opt-out from this behavior (other than renaming my MH> conditional)?
Not outside of redefining %dist. If an opt-out is important, the conditional could be changed a bit:
%__bootstrap ~bootstrap %dist %{?distprefix}.fc31%{?with_bootstrap:%{__bootstrap}}
Then you could %define _bootstrap %nil in your spec to avoid this.
[root@test-rawhide rpm]# rpm -D "with_bootstrap 1" -E %dist .fc31~bootstrap [root@test-rawhide rpm]# rpm -D "with_bootstrap 1" -D '__bootstrap %nil' -E %dist .fc31
- J<
On 11. 03. 19 19:25, Jason L Tibbitts III wrote:
"MH" == Miro Hrončok mhroncok@redhat.com writes:
MH> Is this something that we actually want? E.g. I was quite surprised MH> by the behavior.
What about it is surprising? You remove the bootstrap bit and without changing anything else you have a package which sorts newer than the previous with-bootstrap package. Even though we haven't yet run short of integers, I can see the utility in this.
I was bit by this in copr when I rebuilt something from Fedora without bumping and it and it got lower nevr than Fedora official build. Obviously I should have bumped the release, but I was surprised nevertheless.
MH> When I bootstrap, should I manually bump the release number or let MH> this magic happen?
Well, obviously you have to bump it once. Whether there's any utility in saving you from having to bump twice is up for discussion, but certainly you can.
I'm OK with not bumping the release manually when I build the non-boostrap build. I just wanted to know wheter it is considered OK.
MH> Also, how do I opt-out from this behavior (other than renaming my MH> conditional)?
Not outside of redefining %dist. If an opt-out is important, the conditional could be changed a bit:
Not sure yet, but we certainly have opt outs for a lot of things.
%__bootstrap ~bootstrap %dist %{?distprefix}.fc31%{?with_bootstrap:%{__bootstrap}}
Then you could %define _bootstrap %nil in your spec to avoid this.
Let's do this?
Dne 11. 03. 19 v 20:45 Miro Hrončok napsal(a):
On 11. 03. 19 19:25, Jason L Tibbitts III wrote:
> "MH" == Miro Hrončok mhroncok@redhat.com writes:
MH> Is this something that we actually want? E.g. I was quite surprised MH> by the behavior.
What about it is surprising? You remove the bootstrap bit and without changing anything else you have a package which sorts newer than the previous with-bootstrap package. Even though we haven't yet run short of integers, I can see the utility in this.
I was bit by this in copr when I rebuilt something from Fedora without bumping and it and it got lower nevr than Fedora official build. Obviously I should have bumped the release, but I was surprised nevertheless.
MH> When I bootstrap, should I manually bump the release number or let MH> this magic happen?
Well, obviously you have to bump it once. Whether there's any utility in saving you from having to bump twice is up for discussion, but certainly you can.
I'm OK with not bumping the release manually when I build the non-boostrap build. I just wanted to know wheter it is considered OK.
MH> Also, how do I opt-out from this behavior (other than renaming my MH> conditional)?
Not outside of redefining %dist. If an opt-out is important, the conditional could be changed a bit:
Not sure yet, but we certainly have opt outs for a lot of things.
%__bootstrap ~bootstrap %dist %{?distprefix}.fc31%{?with_bootstrap:%{__bootstrap}}
Then you could %define _bootstrap %nil in your spec to avoid this.
Let's do this?
This looks like nice extension.
BTW this was the last real use case for me:
https://koji.fedoraproject.org/koji/packageinfo?packageID=9380
Vít
"JA" == Jun Aruga jaruga@redhat.com writes:
%__bootstrap ~bootstrap %dist %{?distprefix}.fc31%{?with_bootstrap:%{__bootstrap}}
Then you could %define _bootstrap %nil in your spec to avoid this.
JA> +1 It looks better.
Given the positive feedback, I went ahead and committed this. I was going to send a PR, but went all the way through the process and was told I couldn't submit a PR because of some idiotic rule about signoffs and git commit --amend --signoff screwed with the history on my fork and it wasn't worth trying to figure out how to undo it. So I just committe. Thanks for making me waste my time for something that means exactly nothing.
- J<
packaging@lists.fedoraproject.org
-
Jason L Tibbitts III -
Jun Aruga -
Miro Hrončok -
Neal Gompa -
Nicolas Mailhot -
Vít Ondruch