Tomasz Kłoczko wrote:
> Issue is that sometimes people really don't want (first) to understand how
> to use the exact tool (it starts from something like "I'm not going to
> read anything because I want to just use it!!") or look at some already
> working examples (those cases are even worse :)).
> Those people prefer to discover how to use it without reading even a
> single line of necessary documentation.
> I know that .. because I'm one of those and here probably you can find
> much more such people :P
Well, in the case of autoconf, the main issue is that it is so hard to do
basic things and the documentation is so hard to understand (yes, I have
tried to actually read it and given up quickly) that only a handful people
on this planet actually understand what is going on, the rest of us are
stuck copying&pasting something that happens to work from somewhere,
resulting in cargo-culted broken and/or deprecated snippets everywhere. And
as a result, a compatibility break often affects not just one single
package, but dozens that all copied&pasted the same boilerplate snippet.
> (most of the time [those new tools] are even worse like scon or waf)
I actually agree with you on that part. :-)
> IMO cmake is one tf he worst recent build tooling because it does not
> introduce good standards of some well known operations
Funny, because that's exactly the main issue I see with autotools. ;-) (See
my point above about copied&pasted boilerplate snippets.)
> and only that opens widely all gates for sometimes freakishly
> implementations of doing NormalThings(tm).
Well, I have indeed seen some upstreams doing weird things with CMake,
almost inventing their own build system on top of CMake. But that is not how
CMake is intended to be used.
The main thing magic layers often do is handling bundled dependencies, which
is NOT what I would call a NormalThing. ;-) (And the autotools do not
natively handle that either, so I have actually seen magic layers on top of
the autotools for the same reason.)
> And not only the new autoconf breaks updates of other packages.
> That is an immanent feature of all new versions of all software which
> interact with other software :P
Not necessarily. An upstream that cares about backwards compatibility breaks
few to no dependent packages, and if it does break something, it is usually
an accident and upstream will try to fix the regression. On the other hand,
an upstream like autoconf that does not care causes a trainwreck and blames
the dependent packages for it. I also complain about this issue when other
dependencies (libraries, compilers, interpreters, etc.) do it.
> Nevertheless above part is completely off-topic from the subject
> introduction of the ac 2.71 in Fedora.
>
> I can only repeat that instead of conserving current state and swiping
> some issues under the carpet by introduction of compat-autoconf-2.69 to
> deal with only a handful of packages with some ac 2.71 issues it would be
> better to form a list of those packages.
> Because the new f35 cycle just started now is the best moment to expose
> and sort out all those issues.
The question is, is it at all possible to fix all the affected packages?
There are autotools-using packages that have not been updated upstream for
eons, such as kdelibs3 (which is itself a compatibility library that is
needed to keep applications working that have not been updated upstream for
even longer).
If there are packages that cannot be made to build with autoconf 2.71, we
need the compatibility package and we need it to stay.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
