On 11/16/2018 3:19 PM, Nicolas Mailhot wrote:
Le vendredi 16 novembre 2018 à 13:02 -0800, Japheth Cleaver a écrit :
I'm not sure why punting like this is a good thing. RPM is a
standard,
moving along at what one might expect a core component to do, but to
the
extent that "evolving our packaging" means doing things at odds with
or
in an incompatible way other distros (whether downstream,
"downstream", or not) this is not a feature, or very nice.
I think you do not realise how much old rpm is holding us back, and how
much we limit ourselves in Fedora, and make ourselves more work, just to
cater to those old rpm limitations. A small number of people, that
include Jason Tibbitts, perform unappreciated heroic wonders all year
round to limit the damage old rpm deficiencies inflict on Fedora and
EPEL, and if you think the situation is imperfect, well it would be
terrible without them.
Really, if there is one distro component we should backport to el and
all release streams, that's rpm + all Fedora macro packages, not the
kernel.
Well, that's kind of my point. Packaging changes (not at the core level,
like with the other thread) should not be Fedora-based, they should be
in coordination *using macro packages* across the entire ecosystem.
(Again, Group tag removal seems an obvious example.)
And coming from an EL6 perspective, what "old rpm deficiencies" are you
referring to? Optional Recommends might be nifty new features, but
somehow we're getting along without them still fine. (And, judging from
reports, the semantics and kinks haven't been entirely worked out of
those yet regardless.) If a core rpm forklift can be done safely onto an
old release, then that's an option to be kept on the table (even in a
stable release), but I'm hard pressed to think of any "deficiency" per
se. (%trans processing and %build conditionals strike me as things it
would've be important to backport.)
Classical rpm targets and works well for C/C++ projects that use
autotools, a static small list of dependencies, and release as an
archive. A growing part of the distribution does not fit this model any
more. git and the internet blew away any limit on the number and cadence
of dependencies for every language, including C/C++. Non C/C++ languages
do not fit in the C/C++ macro model. Those new parts needs the same
level of rpm support as previous projects, which means writing new
macros, that build on other new macros, and it all falls appart if you
can not rely on some of those other macros existing because of a time-
jump in el land.
Classical rpm macro argument processing is severely deficient, not even
on par with shell getopts-level of argument processing, let alone the
argparse-level many languages now sport. That creates a huge impedance
mismatch with modern commands that expect more elaborate argument
syntax. You can not drive them from rpm macros, you end up putting lists
of arguments in variables to pass them to commands behind the macro
argument parser. That should be fixed.
If you're discussing things like 3K-character-long java arguments, then
I agree with you that that's painful. But I fail to see how the core
needs of any build system (or install system) can be any more complex
than arbitrary shell, and these sections already *are* arbitrary shell.
I'd like to never have to tweak CFLAGS= in a %build, but it occasionally
does happen. That doesn't mean it's a design flaw -- that's why code is
allowed to be there. In a worst-case-scenario, one can always
standardize on an external helper to adjust or modify things during
execution (which has the added benefit of bench-testability and code
re-use) and use a macro to call that.
I feel like this mirrors the debate between imperative initscripts and
declarative unit files. Macros are great, and macros calling
distro-defined helpers work, but a religious purge of shell does not
really seem to be a win.
Most notably, all the dead-stupid %setup/%sources/Tag
processing, that you know any rpm novice will misunderstand and get
wrong, even before you attempt explanations. Those warts were merely
annoying when dealing with a few thousands of distro packages, they have
a real cost now the distro has grown.
How is this processing "dead-stupid"? I'm seriously asking here. It's
not difficult, and it shouldn't be too much to ask that someone be able
to figure out the syntax of a simple recipe file like this. I agree we
were in an RPM-documentation deadzone for a while there, but I feel like
there are plenty of examples and guides now for novice RPM users.
Certainly seems easier to make an .rpm than a .deb.
-jc
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
