----- Original Message ----- > From: "Nicolas Mailhot" <nicolas.mailhot@xxxxxxxxxxx> > To: "Robert-André Mauchin" <nicolas.mailhot@xxxxxxxxxxx>, "Development discussions related to Fedora" > <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Cc: "Nicolas Mailhot" <nicolas.mailhot@xxxxxxxxxxx> > Sent: Monday, October 22, 2018 10:00:40 AM > Subject: Re: PSA: builds using forge macros with tags broken on rawhide > > 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*). > > 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. > > So, no biggie. Easy to fix. That's why such changes hit -devel before > anyone dreams of queuing them to stable. I think that it would be reasonable to test the changes against the Fedora package base before even pushing the change in to the rawhide. This kind of unnecessary breakage is easily avoidable if you would spent sometime on testing this by scratch rebuilding the Fedora packages locally, prior pushing this. Could we avoid any such kind of regressions in the future? JC > > 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, > > -- > Nicolas Mailhot > _______________________________________________ > 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 > _______________________________________________ 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
