Le lundi 19 novembre 2018 à 11:27 -0800, Japheth Cleaver a écrit :
> On 11/16/2018 3:19 PM, Nicolas Mailhot wrote:
> >
> > 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.
I'm not talking about using macros to ease changes I'm talking about
macros used directly in rpm specs because they save packager time and
effort. You don't get more core than that, if the macros are not there
the specs do not build. And spec ifdefs just create more packager work
than if the macro had not been written in the first place (that's one
reason the number of epel packagers is far smaller than the number of
Fedora packagers).
> (Again, Group tag removal seems an obvious example.)
That would take a specific organisation, to track macro changes, and
organise their backport whenever possible. FPC as it is organised today
does not have the required manpower.
Some macros are just lua and shell code easily backported, others
require an explicit rebuild of the tip rpm to old stable (should not be
a problem because rpm is backwards-compatible but we forbid ourselves
that right now), others backports are plain impossible because they
depend on a specific (other than rpm) component update. EPEL backports
would almost certainly collide with old macro versions in the RH EL part
and on lack of capabilities of ancient shell/rpm.
> 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.
What you call getting along fine is mostly slowing down Fedora
progression so the mismatch with EL does not get completely awful (as
your first message clearly stated).
> (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.
Just a stupid thing like Fedora rpm adding end of lines by default to
echo warn and err has cost me hours patching the end of lines back in my
el backport. And I don't blame Fedora rpm for fixing this, I blame
whoever though EL-side that it would be ok to differ from the Fedora rpm
behaviour for years.
>
> 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.
Before you get to the arbitrary shell part you need to pass the rpm
macro argument parser. It does not understand long options (even if you
have enough letters available for single-character flags "nice" letters
will collide when composing macros). It does not understand repeated
flags (only one flag value possible per call). Realistically for any
semi-complex macro you'll end up defining a magic rpm variable where you
put the arguments you need, and have the macro read this variable
instead of using macro arguments, because any other argument passing
attempt will flounder on the rpm argument processor.
And that's not exotic argument passing invented by awful java devs, even
dnf uses all of those.
> 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.
Yes, classical rpm works ok for C/C++ programs. That's pretty much the
only class of content that does not need long lines of shoehorning in
spec files. Want to bare any non C/C++ package from the distro so rpm
does not need to change?
> 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.
Then you volunteer to review and audit all those wonderful shell lines
in the tens of thousands of Fedora specs? I though not. Writing
thousands of lines of shell code in specs is trivial. Reviewing and
maintaining the result is not.
> > 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"?
On top of my head:
1. awful unintuitive multi-archive support in %setup no one understands
at first
2. # cludging in sources because rpm is pre-internet so internet
downloads are considered exotic tech not worth a Tag to specify the
download filename (as see recently for cran users)
3. unspecified effective workdir, created as %setup side-effect
4. unspecified archive extraction dir. You better know how your sources
unpack beforehand because rpm (that does the unpacking) does not
remember what it did. Papered over by magic cd to workdir, that only
works in the single archive case.
5. Tags that have variable equivalents, but can not be set as
variables,
6. casing games in tag to variable translation (%{SOURCEX} is uppercase,
%{version} is lowercase, where's the logic, Source and Version are
written the same way)
7. asserts all over the place to make sure you write tags and not
variables (asserts that will laughably ask you to set a Tag before
executing the macro that sets it, and will complain after you set the
Tag manually it's now set twice)
8. other gratuituous differences such as Name vs package. God forbid you
could specify the main package name with the same syntax as subpackages
9. No clear end of description marker, that depending on rpm version
(most notably, the EL versions) will make description eat follow-up spec
lines
10. no way to specify any form of structured variables (even the shell
has arrays and lists)
11. no way to specify sets/sructures of variables. Need to write custom
lua code to enumerate sources, patches, and to do any form of variable
grouping.
12. general confusion between what applies to the srpm and what applies
to the rpm, most evident in the fact it's not possible to write a
specific subpackage description for the subpackage that matches the srpm
name
And I intentionally didn’t mention any genuine new functionality, just
problems with existing functions, that are glaring and off putting to
anyone trying to get into rpm packaging, and that experienced rpm
packagers like to forget about.
No ones writes new software in K&R C anymore, shell syntax has improved
over the years, but we're proud to reproduce identically the syntax
warts rpm was born with, two decades later.
That's not the right way to get new packagers and grow the
distribution.
No one in his right mind will choose rpm spec syntax over all the new or
old languages that made the effort to clean up their grammar. What this
tells to any outsider is that we are not confident enough in rpm’s
future, to invest in it. And if Red Hat/Fedora do not invest in rpm, why
should third parties bother with it?
There are lots of things that people do in Ansible now, that could be
done in rpm/specs (obviously, Ansible also permits things that could not
be done in specs. I'm not talking about those). People do those in
Ansible because the Ansible syntax is more modern and regular. But,
Ansible does not make a distribution.
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
