Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

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

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [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