Moving from pkg-config to pkgconf

[rahul]

With pkg-config no longer being maintained, I think we should move to pkgconf. Pkgconf is faster and suports more parameters within the .pc files and crucially is actively maintained. (Pkgconf is a drop-in replacement for pkg-config)

To do this, pkgconf needs to be moved to after Autoconf and Automake because an autoreconf -fiv has to be run in order to generate the configure script. However, there are no side effects to this and all the packages that would've generated a .pc file still do in a fresh build.

Multilib pkg-config also becomes possible now with the addition of personality files.

[rahul]

I also attached a preliminary patch for the multilib book. I know for sure that the personality files work (I used them to compile up to steam successfully), but I have not tested a full build with them.

[Xi Ruoyao]

Replying to rahul:

With pkg-config no longer being maintained

Is this true? Note that "the upstream has found no reason to change the code or make a new release" is not "unmaintained".

I think we should move to pkgconf. Pkgconf is faster and suports more parameters within the .pc files and crucially is actively maintained. (Pkgconf is a drop-in replacement for pkg-config)

Note that "too actively maintained" can be bad for us. If they make a release per week it would be annoying.

To do this, pkgconf needs to be moved to after Autoconf and Automake because an autoreconf -fiv has to be run in order to generate the configure script. However, there are no side effects to this and all the packages that would've generated a .pc file still do in a fresh build.

The only two packages (AFAIK) using pkg-config before autoconf are ncurses and grep. ncurses invokes pkg-config to find the location to install .pc files, but we are already using --with-pkg-config-libdir=/usr/lib/pkgconfig so it should not be a problem. grep invokes pkg-config to find pcre2, but pcre2 is not in LFS anyway.

Multilib pkg-config also becomes possible now with the addition of personality files.

It's already possible now with the current pkg-config, by passing --with-pc-path=/usr/lib32/pkgconfig --with-system-library-path=/usr/lib32 --program-suffix=i686-pc-linux-gnu- to configure.

[Xi Ruoyao]

Replying to rahul:

I also attached a preliminary patch for the multilib book. I know for sure that the personality files work (I used them to compile up to steam successfully), but I have not tested a full build with them.

Multilib branch is maintained by merging trunk periodically. So the patch for multilib should not include the changes already planned for trunk.

[rahul]

Updated to prevent conflicts

[rahul]

Replying to Xi Ruoyao:

Multilib branch is maintained by merging trunk periodically. So the patch for multilib should not include the changes already planned for trunk.

Thanks just fixed it

[rahul]

Replying to Xi Ruoyao:

Is this true? Note that "the upstream has found no reason to change the code or make a new release" is not "unmaintained".

It seems like the project as a whole has gone dormant, I would not count on build fixes being issued in a timely manner anymore as a lot of the issues on the Gitlab have sat unresolved for years.

Note that "too actively maintained" can be bad for us. If they make a release per week it would be annoying.

It seems like they are slowing down with releases, it seems to be every 4-6 months now between releases.

Multilib pkg-config also becomes possible now with the addition of personality files.

It's already possible now with the current pkg-config, by building pkg-config again with --with-pc-path=/usr/lib32/pkgconfig --with-system-library-path=/usr/lib32 --program-suffix=i686-pc-linux-gnu- passed to configure.

I didn't know that, however, at the very minimum we should probably be adding those options to the multilib book, as currently the pkg-config instructions only work x86_64

Overall, I still think the switch is worth it, it shouldn't affect much in the book but it might help in the long term. With many distros, including Debian stable, moving over, package maintainers might start to assume that pkgconf is being used instead of pkgconfig. Which might mean that developers ship .pc files that our current version of pkg-config cannot interpret because of the extra parameters. The package is also smaller and doesn't rely on an included version of Glib (it doesn't use Glib at all). Seeing that it is a drop-in replacement, I don't think there is any harm in shipping a smaller, faster, and more feature-rich replacement

[Tim Tassonis]

Looks nice, and seems not to pull any new dependencies, so I'm all in.

[ken@…]

I agree that pkg-config might be unmaintained, but looking at git issues often suggests that they are for an unusual problem (e.g. trying to build old gtk, probably gtk1, and an old libXi). I'm not convinced that open pkgconf issues are necessarily any better-reviewed.

From the fedora justifications I see nothing likely to be beneficial to LFS or BLFS.

BUT - pkgconf appears to be intended to use meson, autoconf looks like a legacy item which will eventually disappear (and will mean building pkgconf after meson/ninja).

I am puzzled by the assertion it is faster - configuring a package by any of configure or meson does not usually take long (cmake might differ) so I wondered how this was determined, and what difference it made to the time taken to build the package.

Also, for the moment I'm not aware of any current uses of newer parameters, nor of packages where pkgconf is specifically looked for.

I can see that debian has been using pkgconf for a long time (it was available in buster, oldoldstable) BUT the html manpages e.g. ​https://manpages.debian.org/experimental/pkgconf/pkgconf.1.en.html all appear to be the same and dated in November 2016 so I'm not convinced about packages using new options.

[ken@…]

Also, from the open pkgconf issue ​https://github.com/pkgconf/pkgconf/issues/247 the real upstream is ​https://distfiles.dereferenced.org/pkgconf/ (comment on 1st March) and in effect github is only a mirror.

But I find dereferenced.org somewhat impenetrable (one kernel post from last year on first page of git results, one old blog for another user with an expired certificate), one reference to packages being maintained for alpine-linux and ubuntu) - just trying to understand what else is maintained there, and failing, because distfiles/ is apparently not readable. That doesn't mean pkgconf is good or bad, of course.

[ken@…]

Replying to ken@…:

BUT - pkgconf appears to be intended to use meson, autoconf looks like a legacy item which will eventually disappear (and will mean building pkgconf after meson/ninja).

Hmm, reading README.md I see that meson is intended for windows users, configure with unix systems appears to be the long-term preferred method. In which case, theneed to use autocnf with a release sounds like a bug (but yes, I know of at least on BLFS package like that).

But I cannot immediately see what the LICENSE of pkgconf is ?

[rahul]

Replying to ken@…:

But I cannot immediately see what the LICENSE of pkgconf is ?

According to the old homepage (​http://pkgconf.org/features.html) it uses an ISC like license.

In regards to the "if it ain't broke don't fix it" view,pkg-config uses an internal version of glib and a different structure for dependency resolving.

The included glib means that the package is much larger even though pkgconf has its own library. And in the long-term might cause failures from the out of date version of glib that is shipped within pkg-config. The new library might also be useful in the future, even if it is not right now.

As far as I can see there aren't any downsides towards switching.

[rahul]

I don't know what to put for the homepage for this package, looking deeper into it there are 3 options

Pkgconf.org - this seems to be dormant and completely out of date not citing any new version after 1.1

GitHub - this seems to be a mirror but also explains pkgconf really well

​https://gitea.treehouse.systems/ariadne/pkgconf This seems to be another mirror? But this is the one that arch lists as the homepage so maybe this is the official page?

I agree that dereferenced.org doesn't seem very reliable, I think we should just stick to GitHub for now for the download but maybe change the homepage to pkgconf.org

[Bruce Dubbs]

After all the discussion, I'm OK with the change. github seems to be the best choice for the homepage entry.

[ken@…]

Replying to rahul:

Replying to ken@…:

But I cannot immediately see what the LICENSE of pkgconf is ?

According to the old homepage (​http://pkgconf.org/features.html) it uses an ISC like license.

Thanks. I queried that because I thought github specified that everything ought to have a license file.

[ken@…]

Replying to rahul:

I don't know what to put for the homepage for this package, looking deeper into it there are 3 options

Pkgconf.org - this seems to be dormant and completely out of date not citing any new version after 1.1

GitHub - this seems to be a mirror but also explains pkgconf really well

​https://gitea.treehouse.systems/ariadne/pkgconf This seems to be another mirror? But this is the one that arch lists as the homepage so maybe this is the official page?

I agree that dereferenced.org doesn't seem very reliable, I think we should just stick to GitHub for now for the download but maybe change the homepage to pkgconf.org

Umm, dereferenced.org is the official place place for downloads, even though it is not clear what dereferenced.org is all about. I think that this Ariadne has moved around, and treehouse systems is her development system. She updated that on 2nd May, kaniini then committed that the same day.

But, github has no releases. The tags have a tar.gz but the name for 1.9.5 is pkgconf-pkgconf-1.9.5.tar.gz whereas dereferenced.org has pkgconf-1.9.5.tar.xz and that is much bigger- among other things it includes a configure script

OH, and for some reason I had overlooked the COPYING file - not a GPL COPYING file, but sufficiently ISC-like.

[rahul]

Updated patch with dereferenced.org tar, move pkgconf back to original location

[rahul]

Replying to ken@…:

much bigger- among other things it includes a configure script

I did briefly look at the dereferenced.org version but I did not see the configure script. Thanks for the heads up, I can also remove the extraction note now by using that version. And most importantly, pkgconf is now a literal drop-in replacement for pkg-config, since it can now be moved back to its original location (Right after GCC pass 3)

Now I see even less reason not to move to pkgconf.

(Patch updated, multilib patch still seems to apply cleanly)

[Xi Ruoyao]

Replying to rahul:

(Patch updated, multilib patch still seems to apply cleanly)

Let's make it for trunk first, and for multilib-specific things we may need to contact thomas via email or IRC. The multilib branch is considered a personal project.

[Xi Ruoyao]

I've queued the change at 36c4569b9f76. Note that there are several issues in the origin patch so I fixed them:

• The most serious one, it should be <?dbhtml filename="pkgconf.html"?>, not <?dbhtml filename="pkgconf"?>. Or the page for pkgconf will be named "pkgconf" w/o extension. This is strange, and may be unsupported by some Web browsers.
• Do not include irrelevant (format) changes like

           <segtitle>&dependencies;</segtitle>
           <seglistitem>
             <seg>Bash, Binutils, Coreutils, Gawk, GCC, Glibc, Grep, Make,
  -          and Sed</seg>
  +           and Sed</seg>
           </seglistitem>
         </segmentedlist>
  

because a mix of format change and real changes is difficult to review.

• Long lines should be broken down, no lines should exceed 80 characters (expect the lines in <screen>).
• Typos like "mantain", missed ':' after "create a symlink", missed whitespace before "(", etc.
• I've also removed the short description for "pkg-config" symlink because generally we don't have short descriptions for symlinks.
• This change replaces a package with another, so it should be documented in whatsnew.xml, see 654a2f9ede50.

[Xi Ruoyao]

Fixed with:

• 138b87f8d (changelog: Add ticket number for pkgconf change)
• 7cb24f473 (Package updates)
• 654a2f9ed (whatsnew: Update for pkgconf change)
• 36c4569b9 (Replace pkg-config with pkgconf)

[Bruce Dubbs]

Milestone renamed