Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> there is also the possibility to provide a working %description closing > statement %end does close %description, but what it cannot return to the preamble, which is what you're asking. The space after an %end (regardless of what it closes) until the next section begin is kind of no-mans land where only whitespace, comments and macro definitions may live. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-617584572___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
Closed #1161. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#event-3251121093___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
Now documented in https://rpm.org/wiki/Releases/4.15.0 (https://github.com/rpm-software-management/rpm-web/commit/5e77e83f004f07fbfcf88bd3a69ac81c9a373d47) and rpm will issue a warning on undefined macros in buildtree macros (commit 701736a18a4625557a5181df3a4f3aed7ac13506). Case closed, thanks everybody for the feedback. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-616459026___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> I can not leave the specs “alone”. There are lots of packagers involved. I
> can not forbid them to set sourcedir (as has been documented since forever),
> and I can not forbid them to add patches to their spec files, using %{name}
> as is the Fedora best practice, which breaks instantaneously (as evidenced by
> the dejavu case).
They've managed just fine for about a year. I'm quite confident they'll manage
in the future too. The dejavu-patch was added by yourself, others haven't had
any issues with this.
There's quite clearly some profound misunderstanding here (this got derailed
very early on) about the nature of the change and when it happened, and I'm
clearly not able to communicate this in a way that gets the message through. I
give up now. Others are free to try.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-611409588___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
(and again, there is also the possibility to provide a working %description closing statement, which would enable putting Sources and Patches just before `%prep`, which is the correct code flow location for those 1570 specs, and aligns with your internal rpm behaviour requirements) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-611405059___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
@pmatilai I can not leave the specs “alone”. There are lots of packagers
involved. I can not forbid them to set sourcedir, and I can not forbid them to
add patches to their spec files, using %{name} as is the Fedora best practice,
which breaks instantaneously (as evidenced by the dejavu case).
When that happens they will all get back to the guidelines author (me) and ask
for fixing the guidelines, because that is not their responsibility to adapt
guidelines that break in the field. In fact there are already been several
breakage reports in the past year (in Fedora CI, and other systems) that I had
not understood yet because the jenkins Fedora CI logs suck and what was broken
when things had already built fine for thousands of times and no backwards
compatibility breakage had been announced was unclear.
As for making Name: declaration a manual hack. What kind of advice is that? Do
you really have no clue how widely %{name} is used and expected to be used in
Source and Patches? The change make this decades-old common pattern radioactive
and dangerous to use.
But, if you want to go this way, at least do it cleanly. Make it an official
rpm variable (for example %{source_name} and set Name to %{source_name}
automatically at %{prep} time in rpm
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-611399214___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> Just give me a canonical pattern for those two specs and I’ll shut up.
I already told you multiple times (after some initial confusion): just leave
the specs alone, they're not broken.
The only thing you should change is your personal rpmbuild setup to not use
%{name} or other spec-defined macros in the build tree macros.
Which is what I said in my earlier, long comment from this morning. Please
actually read it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-611384722___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> (The downside of expanding multiple times is that it is not easy to have a
> literal '%' character in the patch name.)
Not a problem anymore, there is a `%{literal}` (or whatever it ended up being
called) in rpm now
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-611379681___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
@panu: then I will apply your advice blindly, as you give it blindly, and you'll have 1570 FTBS packages in a week. Do you think you’re the only one who can play the idiot? Just give me a canonical pattern for those two specs and I’ll shut up. You seem utterly unable to do so. Maybe that’s because all this theory is fluff that does not work in practice? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-611378414___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> Therefore, the change makes them all latent build failures, as soon as the
> packager attempts using %{name} in sources, patches, or sourcedir (as
> evidenced by the breakage when dejavu-fonts needed its first patch in years).
Once more: this has been in Fedora and other distros for almost a year. World
hasn't ended, I hadn't heard a single mention of it until now. Those packages
have been built a lot in the meanwhile.
Avoiding use of macros before they're declared is all that is needed, it's not
as if you can't write source/patch names literally if that's what the pattern
in these packages requires. Use of %{name} in throughout specs comes from
wanting to avoid repetition, but much of the time it's not really the right
thing to use to begin with: the *package* name could change, upstream name
doesn't. You don't have to use *%{name}* to avoid repetition. Declare your own
naming macro (`%define myname foo` or whatever) at the top of the spec and use
it for the rest of the spec, including in the actual Name: tag. Which frees you
from the ordering constraints that force you to put Name later than usual in
the spec.
The only real victim here is use of spec-defined macros in %_sourcedir (and
other similar paths), which always was a "kinda works" thing at best. Of course
by accident is not how you want to introduce compatibility breaks, but
sometimes stuff happens nevertheless. If this had been brought up last summer
during 4.15 development stages I would've been more inclined to revert at least
temporarily, but evidence suggests that this isn't a common setup, and for a
reason. I'd really recommend switching to the dist-git style per-package setup
based around $PWD that most of the world has settled upon by now, as that's
where rpm is headed too once somebody figures out how to handle the transition.
One off-line realization from yesterday evening was that the former behavior of
re-expanding source/patch paths on use throughout the build means that it's
possible to change them as well, so you could use different material for
building than what ends up being packaged in src.rpm. That, along with the
other escape etc issues that come with multiple expansion (eliminating which
has been a bit of a theme in 4.16, although this happened much earlier), and
simplicity of "declare before use" rule all seem supportive of what we ended up.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-611350130___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
There is no "new evaluate on declaration thing". Rpm always evaluates macros
when it parses lines.
How do you think macros like
```
%perl_req Requires: perl = %{perl_version}
```
work? You can also do something like this:
```
%define p0 Patch0: patch.diff
%p0
```
There is no way to get rid of that initial expansion. The question is whether
we should go back to expanding the source/patch tags twice for compatibility
reasons. Even if it's an undocumented and unclean feature that wasn't intended
that way-
(The downside of expanding multiple times is that it is not easy to have a
literal '%' character in the patch name.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-611201614___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> Please stop spreading FUD about thousands of specs breaking. They're building
> just fine, here's an
> example scratch-build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43124256
The *documented* *official* packaging pattern this change broke is used by at
least fonts and go Fedora packages
```console
$ dnf --disablerepo='*' --enablerepo=koji-builds repoquery --whatprovides
'golang(*)' -s -q | uniq | wc -l
1240
$ dnf --disablerepo='*' --enablerepo=koji-builds repoquery --whatrequires
fonts-filesystem -s -q | uniq | wc -l
331
$ date --rfc-3339=seconds
2020-04-08 13:58:38+02:00
```
So that’s 1571 sources packages in the F33 koji build repo as of now.
All of those use either the sil-mondulkiri-fonts or sil-mondulkiri-extras-fonts
documented and official declaration ordering pattern. Therefore, the change
makes them all potential build failures, as soon as the packager needs to use
%{name} in sources, patches, or sourcedir.
Now so far I’ve been assuming good faith, that you wanted to clean up things
and make them better (for everyone, not just for you as an rpm dev). Therefore,
I’ve asked you to define what good common solution you wanted applied tor those
patterns, so those 1571 packages can be refactored before the breakage is
triggered. And I’ve proposed to take upon myself, to document the new pattern,
go get it approved by FPC, to fill the Fedora change pages to get those
packages changed, to get blamed by packagers for gratuitous packaging guideline
changes, etc (ie, months of thankless tedious uninteresting work).
The documentable and actionable spec fixing options (as in, when you fix the
spec files, not when you break them in mass waiting for others to fix the mess)
are:
1. revert the change, keep things working as they were
2. evaluate Sources/Patches on non-internal use (at the point the srpm is
created)
3. evaluate Sources/Patches at %prep (make it an explicit expansion barrier)
4. keep the new ”“evaluate on declaration” thing (though the more this goes on,
the more you are convincing me it is ill-though and dangerous), and *as* *a*
*consequence* fix the unbounded description misbehaviour that required, moving
Sources/Patches before the rest of the rpm headers for automation to work;
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610923847___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> After several days and multiple requests, you’ve still not proposed any
> clear, common and future-proof place where to put Source declarations in
> those specs.
I think it's been pointed out several times now that it's not a matter of spec
tag order, but macro definition. Citing @mlschroe 's example:
```
Patch0: %{foo}
%define foo bar.diff
```
This is no different really.
Please stop spreading FUD about thousands of specs breaking. They're building
just fine, here's an example scratch-build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=43124256
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610900643___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> > sil-mondulkiri-fonts and sil-mondulkiri-extra-fonts are representative of ~ > > 1000 Fedora specs (not just fonts, I gave 2 fonts specs as testcases > > because they are simpler without %build-related complexity). > > And to make this clear to anybody observing this discussion, these continue > to build just fine as they have done all this time. It's only a specific, > non-default (and non-recommended [*]) setup where things start to break > because there are macros in %_sourcedir that are only defined during spec > parse. After several days and multiple requests, you’ve still not proposed any clear, common and future-proof place where to put Source declarations in those specs. Shall I conclude that you have *zero* intention of owning up to the consequences of the change you want to keep? And that the whole issue is just about finding excuses to shove those specs, and the thousand or so packages they represent, under the bus, asking others to fix the regression and breakage without any help from you ? Shall I begin the formal process of requesting arbitration Fedora side if there is nothing to discuss here then? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610890698___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> > Can it be fixed to expand on use? That’s the useful functional place to do > > it. > > It's still effectively on the first use, the gotcha is that the first use is > actually by rpm itself right That’s 100% uninteresting for rpm users, because that make specs depend on internal ill documented rpm artefacts, and effectively makes this internal behaviour a public API (with all the constrains of a public API, and the usual conflicts whenever rpm devs will attempt changing this API). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610887954___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> sil-mondulkiri-fonts and sil-mondulkiri-extra-fonts are representative of ~ > 1000 Fedora specs (not just fonts, I gave 2 fonts specs as testcases because > they are simpler without %build-related complexity). And to make this clear to anybody observing this discussion, these continue to build just fine as they have done all this time. It's only a specific, non-default (and non-recommended [*]) setup where things start to break because there are spec-defined macros in %_sourcedir. >From which we get back to the point of this ticket: how to make the related >undefined behaviors clearer? Warnings on undefined macros would be one >concrete thing to do, but IIRC there's at least one place where rpm itself >expects to be able to pass undefined macro unharmed through the spec machinery >to achieve something (details escape me atm) [*] "Non-recommended" probably only in tribal knowledge from past 20+ years, I doubt it's actually anywhere in our documentation. Which would be another concrete thing. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610785173___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> You did not write which one was removed, but from the effects I see I suppose > it was the expansion on use, right? but from the effects I see I suppose it > was the expansion on use, right? Actually it was expanded more than twice, more like half a dozen times at different sites of use. > Can it be fixed to expand on use? That’s the useful functional place to do it. It's still effectively on the first use, the gotcha is that the first use is actually by rpm itself right after parsing the Source/Patch line: to define the corresponding %SOURCE/%PATCH macro and Lua variables (and if enabled, attempt download). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610777128___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
@mlschroe Thanks for the clarification. You did not write which one was removed, but from the effects I see I suppose it was the expansion on use, right? Can it be fixed to expand on use? That’s the useful functional place to do it. To quote the first message in the issue: > I tend to be of the opinion that this is to be expected, you need to define > values before you can use it, ie the useful functional expansion barrier is at use, taking Panu’s own words. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610482445___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
Btw, what the commit changed was that the Source/Patch arguments are no longer expanded *twice*. They used to be macro expanded when the tag was parsed and then expanded again when the files were used. This issue is not a tag ordering issue at all. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610474749___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
@ffesti then please propose a solution for the two posted spec files. That’s just 2 spec files. They’re not even doing any complex building, just copying stuff around. That should not be hard if you understand the change implications (I definitely do not). If just 2 specs defeat you, how can you honestly write it’s just fixing a few packages? It’s easy to break compatibility because you know better. If you know better, why are you asking others to fix the resulting breakage? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610407307___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
My 2cts: The current behaviour is right. I see not reason to make an exception - neither for `Source:` and `Patch:` nor for `Name:`. Yes, this may break a few packages. Those need to be fixed. Overall the way of how macros are expanded could be made more clear in the documentation. There are a lot of things that are not immediately obvious - e.g. how build script templates from the macro files can be over-written in the spec. Nevertheless we should aim for an easy model with as little exceptions as possible. https://github.com/rpm-software-management/rpm/commit/93604e2c3b8ed8a2b1ac77c4c43856e68b395c49 does just that. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610385692___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> @nim-nim, I'm also just stating facts I can verify. The changed behavior does > exist in rpm 4.15, I can trivially reproduce that here. So somehow the lines, > or facts, don't seem to meet. I don't know what to make of that, so I'm > trying not to draw any conclusions before I understand what's going on. Anyway the past is the past, finding a way forward is more interesting and useful than rehashing history. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610360639___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
@nim-nim, I'm also just stating facts I can verify. The changed behavior does exist in rpm 4.15, I can trivially reproduce that here. So somehow the lines, or facts, don't seem to meet. I don't know what to make of that, so I'm trying not to draw any conclusions. I haven't given any operational guidelines because I DONT HAVE THEM. That's why I opened this ticket - to discuss this in the community and try to draw those lines, within the realm of what is possible. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610351364___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
@pmatilai I’m just stating facts, some of the broken specs were not even written before april of this year, so it is 100% impossible they passed using an older rpm version (and their main build box runs rawhide, not even F32 beta). I gave you concrete, actual production Fedora spec files in the rhbz bug. Just find an order (the same in both 2 specs, after rpmspec -p expansion to make sure it is the actual same order) that rpm upstream is ready to support. and I’ll apply the result in my specs, my macros and the Fedora packaging guidelines. I’m 100% uninterested in “you’re doing things wrong” messages that can not be translated into operational guidelines. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610340943___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
@nim-nim , but it did. See line 141 of build/parsePreamble.c in http://ftp.rpm.org/releases/testing/rpm-4.14.90-git14653.tar.bz2, that's commit 93604e2 right there, and of course it's visible in git logs as well. Which is why this all seems so bizarre. @mlschroe , FWIW I generally totally agree with that, because it's such a *dead simple* rule. Which is why I'm really reluctant to revert to former behavior which special-cased a couple of tags through whatever happenstance (whether it actually was intentional is lost in history of bad commit messages) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610327244___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
My 2 cents: I don't see what macro expansion has to do with the free order of
spec tags. It's should not surprise anybody that using %name does not work
before the "Name:" tag is given.
And how is the following different?
```
Patch0: %{foo}
%define foo bar.diff
```
This has nothing to do with the order of the tags.
I'd *hate* if rpm would insist on some specific order, though.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610317827___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
The breakage didn’t land in Fedora in June 2019. It breaks specs that passed validation and import as late as Fedora 32 freeze (2020-02-25). ie stuff so recent and shiny it has not even landed user-side yet. You won’t see any mass breakage from this change before the next Fedora mass rebuild, in 6 months, for Fedora 33. Please fix it before it comes to that. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610311649___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
Yup, 13730 uses of %{name} in SourceX in Fedora as of a few days ago. The world
didn't break on the day 4.15 landed in rawhide (June 2019) because they declare
Name before using it. Which just comes back to the same old, referencing
"variables" before declaring them doesn't generally work.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610286641___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
You can have the same effect with %{name} as part as the source or patch
filename (which is hardly unknown-of, and is the best practice Fedora-side for
naming patches for example), so the sourcedir part, while an easy way to
trigger the problem, is not the only way to trigger it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610269510___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
Well, hence this ticket! That a change uncovers some previously unnoticed pile
of dirt is nothing new.
And again, the problem described in the bug *only* affects a setup where
spec-defined elements such as %{name} are part of the %_sourcedir, which is
another wholly undefined territory.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610268116___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
As i said in the rhbz issue, no problem adapting existing specs and guidelines to some new ordering, as long as this ordering is clearly defined and rpm upstream commits to it. However, I am completely opposed to changing things that worked in the previous undefined space, to something that works today but is still in the undefined space and may break from one day to the next as a side effect of rpm code changes. Right now, I'm seing rpm upstream moving dirt from one carpet part to another, without committing to anything, while asking rpm users to do a lot of work to adapt to this dirt move. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610264062___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
@nim-nim , note that the backing out the change would only swipe dirt back under the carpet. It's not like everything was alrighty before that source/patch change, it was always broken but you just didn't happen to hit them. Also the fact that this only came up now suggests that its' more of an issue about using spec-defined components in %_sourcedir, which always was a chicken-egg problem and discouraged. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610242413___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
This is also not about any single change, just inspired by that. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610224405___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
And BTW, please do not add more breakage just to prove rpm upstream can break as many things as it wants to. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-61088___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
Then just back-out the change. It’s sole justification is to make things “cleaner”. Now, as soon as it breaks existing specs, you tell us things are arbitrary and will be continue arbitrary. Well if that is the case there is *zero* justification to break the existing spec landscape. If things have no hear nod tail, and will continue to have no head nor tail, why are you considering breaking packages? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610221872___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
This is not about how things *ideally* would be, this is about the existing spec reality. Which is that the spec is not a declarative language but a weird piece of script that executes from top down with multitude of arbitrary side-effects all along the way. It's not possible to change that without a full redesign from scratch, the side-effects are way too deeply rooted in rpm and the specs out there. That it *looks* declarative is deceptive, and that's what this ticket is about - what can we do to make people more aware of the reality. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610211002___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> I tend to be of the opinion that this is to be expected, you need to define
> values before you can use it,
> But all this does raise questions about the allegedly free order of spec tags
> (and sections). Clearly it never was entirely free due to side-effects such
> as the above, but it for many/most purposes it does appear that way.
Thinking about it some more, it is a mistake to evaluate SRPM-related tags at
the point they occur and not at the end of the section (It may also be a
mistake to evaluate RPM-related tags, but scoping for subpackages is quite
under-defined and I’ve been known to complain about this :) ).
First, because Tags and macros/variables are supposed to behave the same
(maximum rpm calls %description a tag, for example).
And second, because macros/variables do support delayed evaluation. The rpm
language is not a programming language where you need to define things before
you use them. That’s the whole difference between `%{foo}` and `%{?foo}`. It
exists so `%{foo}` can be referenced before it is defined, and only be
evaluated at the last moment. And the last moment for SRPM construction is
before `%prep`, not at the point the Tag is declared.
> Thoughts, comments, rotten tomatoes...?
🍅 🥚 🍅 🍅 🍅
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-609034089___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
The change break specs that relied on early Source definition to workaround the
unbounded behaviour of `%description`
* SourceX then (sub)package headers →
```
error: Bad source:
/var/lib/builder/rpmbuild/SOURCES/%{name}/dejavu-fonts-version_2_37.tar.gz: No
such file or directory
```
`%{name}` is not evaluated
* (sub)package headers then SourceX →
```
error: No source number 0
```
`%description` eats the source declarations
* (sub)package headers then `%end` then sourceX (rhbz#564613 "fix") →
```
error: line 149 doesn't belong to any section: Source0:
https://github.com/dejavu-fonts/dejavu-fonts/archive/version_2_37/dejavu-fonts-version_2_37.tar.gz
```
Source declaration is ignored
All (sub)package headers are generated the same way, putting sources in a magic
place in a magic block does not work
```lua
name = sub and "%package -n " or "Name: "
print(
name ..
rpm.expand(
"%{currentfontpkgname}\n" ..
"Summary:%{currentfontsummary}\n" ..
"License:%{currentfontlicense}\n" ..
"BuildArch: noarch\n" ..
"BuildRequires: fonts-rpm-macros\n" ..
"Requires: fontpackages-filesystem\n" ..
"%{?currentfontpkgheader}\n" ..
"%description -n %{currentfontpkgname}\n") ..
fedora.wordwrap("%{?currentfontdescription}") ..
"\n")
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-609017697___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
Actually, if there was a way to report undefined macros, that would be probably also helpful. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-608369178___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
> you need to define values before you can use it
This would be the only assumptions I would make. I would not go further.
However, part of the problem is, that it is not obvious that parsing `Name`
defines `%{name}`. I am not sure this is documented and AFAIK, there is no way
to see this process in action, e.g. see this somewhere in verbose output.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-608368767___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)
Just got this [bug report](https://bugzilla.redhat.com/show_bug.cgi?id=1820349)
where some packages had stopped building, reason being previously unnoticed
regression (of sorts) in rpm 4.15 in a situation where a source or patch refers
to %{name} before its declared. Eg:
> Patch0: %{name}-urn-dtd.patch
> Name: dejavu-fonts
Much to my surprise, this used to work in rpm < 4.15, but bisecting shows it
was broken by commit 93604e2c3b8ed8a2b1ac77c4c43856e68b395c49 which claims to
have no functional changes, but clearly it did as spec parse now fails with
"error: Bad source: %{name}-urn-dtd.patch: No such file or directory"
I tend to be of the opinion that this is to be expected, you need to define
values before you can use it, and that this only ever worked more-or-less
accidentally. If you similarly do
> Group: %{name} group
> Name: foo
...it'll end up with a literal `%{name}` in the group tag in all rpm versions,
and ditto for all/most everything else except sources and patches. I can't see
any meaningful reason for such an exception, instead I think we accidentally
made it all that little bit saner by removing yet another special case.
But all this does raise questions about the allegedly free order of spec tags
(and sections). Clearly it never was entirely free due to side-effects such as
the above, but it for many/most purposes it does appear that way. And of course
we can't start imposing order on the mess just like that, but I wonder if we
shouldn't try nudging people towards a more de-facto order. Maybe starting with
issuing warnings if name/epoch/version/release are not the first tags in a
spec, or something like that.
Thoughts, comments, rotten tomatoes...?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
