@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
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
Le lun. 23 mars 2020 à 15:47, Panu Matilainen a
écrit :
>
> On 3/23/20 3:22 PM, Panu Matilainen wrote:
> >
> > So soon you say? Well, its almost a year since 4.15 alpha and annual
> > release schedule isn't *that* fast. More like trying to get back on
> > track with this release stuff after some
Le mar. 7 avr. 2020 à 12:08, Thierry Vignaud a
écrit :
> > So soon you say? Well, its almost a year since 4.15 alpha and annual
>
>> > release schedule isn't *that* fast. More like trying to get back on
>> > track with this release stuff after some erratic years.
>> >
>> > Anyway, here goes. The
@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
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
> @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
@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
@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
Merging manual provides with automatic provides (with manual ones
overriding automatic ones) would prevent us to detect manual provides that
can be removed b/c the automation took care of it…
Le mar. 7 avr. 2020 à 13:09, Miro Hrončok a
écrit :
> Would it be to hackish to merge 0 with whatever
And as a side note, I suppose I cannot read the existing provides from the
dependency generator?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@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
Would it be to hackish to merge 0 with whatever is generated by generators,
preserving 0 (as in: the manual one wins over the generated one).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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
This is an old problem, not specific to 4.16 at all. Those provides will have
different flags in them, which prevents them from being merged (in existing
implementation). Similarly this will create three different requires:
```
Requires: /bin/sh
Requires(post): /bin/sh
Requires(pre): /bin/sh
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,
Have this spec file:
```
Name: python3-double-provides
Version:0
Release:0%{?dist}
Summary:...
License:MIT
BuildArch: noarch
# This adds the provides manually provided below
BuildRequires: python3-rpm-generators >= 11
# Manually add the provides
Le lun. 23 mars 2020 à 15:47, Panu Matilainen a
écrit :
>
> On 3/23/20 3:22 PM, Panu Matilainen wrote:
> >
> > So soon you say? Well, its almost a year since 4.15 alpha and annual
> > release schedule isn't *that* fast. More like trying to get back on
> > track with this release stuff after some
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 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
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.
--
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
@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
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:
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:
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
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
27 matches
Mail list logo
