Re: <DKIM> Re: <DKIM> Re: Proposed Fedora packaging guideline: Forge-hosted projects packaging automation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Neal,

> And the issue you're having that requires %setupargs is not a problem
> in RPM 4.14

I don't have an issue with  %setupargs, I have an issue with requiring packagers to change stuff in the spec header *and*
at %prep level, which is not in the same place of the spec. That is something which has wasted huge quantities of man-hours in the past, even for experienced packagers.

The automation knows how the downloaded source archive will be named, what is the structure of the source archive (the arguments that need passing to %setup for this archive). The question is just how to pass that knowledge from the automation macro call to %setup or %autosetup.

Overriding %setup makes this work transparently with little risk.
If there is a strong opposition to that what is the best way to achieve the same result?

Using a specific setup-ish macro name like suggested by Panu is trivial technically but has the huge drawback that it requires a specific call by the packager (and many will forget it, at least as first). So it de-optimizes the packager workflow. I'd frankly prefer to optimize the packager workflow over helping tooling – that's what costs actual money and potential contributors.

If there is now way to do it cleanly or safely in rpm, I'll de-optimize the packager side. I don't want to cause problems to anyone. But that would be pretty sad.

Regards,

-- 
Nicolas Mailhot
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux