On 22 January 2018 at 03:39, Neal Gompa <ngomp...@gmail.com> wrote:
[..]
> Personally, I'd like it to be easier to make multi-distro spec files
> by leveraging the increasing commonality among distributions. It's
> already not that bad these days, the main issue is what RPM features
> are supported for each target distribution. Making things less ugly
> for gracefully degrading would be very nice. :)
As long as you are joking I'm ONE HUNDRED PERCENT sure that is is not true
and I can prove this 😀
Proof:
When I've been leading PLD development I had around few really talented and
brilliant people.
In many occasions, we found that standard rpm set of macros have some
issues or those macros had not enough functionalities.
So completely institutionally we started adding some macros or patching
those macros.
For quite long time we have been trying to push as much as possible to rpm
original source code,
You may don't know this but guess who exactly for example discovered %bcond
.. Pawel Gajda or Arkadiusz Miśkiewicz (probably second one but I may be
wrong).
Only when handling %bcond has been accepted and provided by original rpm in
relatively short time we started using it in many specs files.
So yes .. %bcond it is/was ORIGINAL PLD invention.
%bcond handling it is/was only two lines patch!!
After this was second patch next two lines with %{with <foo>{:<str>},
%{without <foo>[:<str>]}
Even today after ~15 years integrate %bcond in rpm many Fedora packagers
are refusing patches switching to %bcond.
Another PLD useful %bcond related feature about how it was used ..
IN PLD %bconds declaration was ALWAYS on the top of the spec after first
(commented) line (with CVC/RCS tokens).
In Fedora %bconds declarations is possible to find almost EVERYWHERE
OK .. in most cases it is on the top but there is no Fedora standardization
about indenting those declarations which usually makes those declarations
not easy to read and quickly understand.
The similar history was with many other things like start populating
LDFLAGS, CFLAGS, CPPFLAGS, FFLAGS to %configure.
The same was with pushing CC, CXX ant other.
In CVS repo with all specs we had example.spec file which was necessary to
modify/update if something new was introduced.
This spec had no single line of comment and was used as reference for other
committers how to use some features/macros, how to format spec
in Fedora there is no such self-explanatory spec and all crucial details
are spread across many different corners of the Fedora documentation.
Because all those details are not on the single web page there is some
number of contradictions in such documentation.
Back to PLD and what caused so many variations of using this software ..
Initially, %confiigure was only "naked" macro wrapping configure and some
set of --dir<foo>=%{_dir<foo>}. Initially many --dir<foo>=%{_dir<foo>}
mapping was missing and in PLD first started fixing this and pushing to the
rpm source tree ..
Since we've integrated those changes in RPM it started speeding like a fire
across other distributions.
>From this time in PLD comes exact way of overwriting those flags and
compilers/linker like:
%configure \
CFLAGS="<flags>" \
LDFLAGS="<flags>" \
<other configure switches>
Why it was and IMO still IS!! *better* than using sometimes few exports
before %configure? 🤔
Because if it was an issue caused by altering those flags in the exact
package it WAS ALWAYS possible to *guess* where something needs to be fixed
(even typo)!!!
Instead of asking yourself "bl*dy he*ll .. where those altering
compilation/linking flags is? .. in which one export line and how fare
before %configure?😨".
No .. no such losing the time!!!
GUYS .. STANDARD SPECS FORMAT/INDENTATION saves a lot of time even for
single packager!!!
This is why I've mentioned about this few times in last few days (in
slightly different contexts) and *trust me I'll be nagging* about this on
any possible occasion 😎
This may speed up whole Fedora development DRAMATICALLY!!! despite other
"deposits" of such development improvement which I'm already trying to
explore ..
So .. I would be really glad to see in Fedora specs like ONLY above
altering %configure as it is in above example. Why? because this precise
place in specs where using editor we need to jump to correct those
altering😎
Again "ab ovo" ..
So what was the strategy or real movements of the RedHat people?
I may be not 100% correct but I think that just before rewrite rpm from
perl to C they've started to ignore what is in standard macros set and they
formed redhat-rpm-config package which is just dropping few files in some
directories which are overwriting.
I'm not sure why RH stopped pushing own macros to rpm source tree .. JFDI?
lack of proper communication and understanding rpm developer needs of
large-scale using rpm? Usual Linux NIH syndrome or just fact that quite
early into rpm main "macros" file has been added possibility to include at
the end per distribution extensions?
I think that because those standard macros at this time started to require
very frequent/instant changes it was easier to split all macros to own
macros file and maintain them inside the distribution. However, I may be
not fully right and it may be as well the mixture of other above reasons.
=======
So I think that real disaster started when SuSE started using rpm and it
was necessary to answer on some influential people JFDINs!!!
At this exact point in rpm history started real kind of disaster ..
=======
OK .. sorry to be so off-topic on my own thread 😕
Please come back to add some missing facts about my original 6 out of 8
points 🙄
If you cannot find some answers maybe you can pull sleeves one of your
colleagues .. telling him "dude I think you should read this" 😎
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
