Nicolas,
On 10/22/2018 10:00 AM, Nicolas Mailhot wrote:
Le lundi 22 octobre 2018 à 00:31 +0200, Robert-André Mauchin a écrit :
Yeah all "gosetup -q" (which is gofed default) are broken because of
your commit:
Well I know no such a thing, there was never any gosetup macro in the
macro set, and I think I told you a year ago I would not define a
gosetup macro just to avoid typing forgesetup, unless it actually added
some processing over the forgesetup macro. That would obfuscate specs
for no good reason and increase gratuituously the maintenance surface
(as we see *now*).
Yet, you were aware of that. And, it was me who told you I am fine with
most of the go macros you implemented, including their names. We both
spent many hours improving the implementation, extending golist binary I
provided. And the %gosetup was the only macro I wanted to keep so all
the regular go macros are in %goVERB form. We have %gometa, %gosetup,
%gobuild, %goinstall, %gotest on purpose so they reflect:
- meta: after some effort even meta can be interpreted as a verb, i.e.
meta the macros
- setup: extract the tarball and prepare working dir
- build: set gopath, build go binaries
- install: install resources under proper directories
- test: test installed go packages
Do you ignore that fact on purpose? Since after discussion we had so
many times you still seem to put more emphasis on your own and only your
opinion. I though we made a compromise and that we agreed on that. I.e.
I will respect all the macro names you choose up to the only one and you
will respect the gosetup one. After having merged your changes you are
sending me a message that even if we come to a common agreement you
still don't care as long as you reach your own goals. I would really
like to think I am wrong in this opinion. Though, you actions say otherwise.
And I doubt -q is your problem, since (*precisely for backwards
compatible reasons) it is still accepted by forgesetup (even though it's
ignored, because it’s the default behaviour now).
Oh, I see, I forgot to add a phantom -q to forgeautosetup as it already
was already its default behaviour. So you're forcing somewhere a -q that
I don't think was ever needed. I will add the -q to the macro definition
if that makes you feel better.
You were the one that implemented the forge macros (pardon me if I am
wrong, I am unsure if it was all of it of most of it). And I love those
macros since they save so much time and make the spec file a lot
simpler. So its natural to be protective if anyone wants to change them
they way that does not align with your world view. Yet, go macros
started to rely on the forge macros and the change you made is not
backward compatible (given we started using the macros in older versions
of Fedora as well). So please, make the %forgeautosetup compatible with
the %gosetup again.
Once the %gosetup macro is functional again, we can discuss its removal
in favor of forgesetup as part of global announcement so all go
packagers have time to migrate to new macros.
For future reference, please don't change the forge macros in any way
that makes the go macros incompatible or broken until we have official
Go packaging guidelines and set of macros the go-sig community agrees on.
Thank you Nicolas
So, no biggie. Easy to fix. That's why such changes hit -devel before
anyone dreams of queuing them to stable.
What package exactly installs your gosetup macro in /usr/lib/rpm so I
can see what other things it tries to do? I see no macro file in the
Fedora gofed package manifests.
If you could PR your changes to the official Fedora packages that
coordinate Fedora go macros (the go-macros repository on github, that
will be rehosted in pagure as soon as the @rh contributors ok the move)
instead of doing it in other places, that would be a tad easier to
coordinate.
Please revert this, we should be able to use whatever flag supported
by %setup and
%autosetup, not a small subset. How do you even pass the basic -n
flags now?
So basically, you have a macro, which sole purpose is to pass
precomputed -n values to *setup, and you want to use it with manual -n
flags. Why? Could you tell us what exactly is the point of
1. wrapping a Fedora macro in another name just because you do not like
the official macro name in Fedora
2. overriding the only thing this macro does over autosetup
3. and then complaining all the argument passing to autosetup does not
work as you wish it does
So all this complexity, because what you really want is to use autosetup
directly. Then just do. What's the problem exactly with typing autosetup
in your spec? No one stops you from doing it.
One reason I removed the -n in forgeautosetup and forgesetup precisely
to stop packagers confusing themselves the way you are confusing
yourself.
The other being -n is incompatible with the processing of multiple
archives that many people asked me to add to the macros. Which is
finally implemented after months of work. And which just hit rawhide
after more than a month of review.
So, do you have actual spec files in Fedora with this use of the redhat-
rpm-config macros? If that is the case, I can put those flags in the
macros so you can continue shooting yourself in the foot using undefined
known-broken use patterns. If not, I'd rather remove the possibility
altogether before someone harms himself.
With you mods, we have to edit hundreds of specs to remove
the -q flags.
And that concretely, if why pre-generating specs instead of making the
effort to include default processing in the macro code Fedora ships is
wrong.
Regards,
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
