Re: dropping autogenerated dependency on pkg-config

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

 



On Wed, 1 May 2019 at 09:04, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote:
[..]
> One of those specs is elfutils.spec in which is:
>
> %check
> # Record some build root versions in build.log
> uname -r; rpm -q glibc

Funny; that’s pretty much
https://github.com/rpm-software-management/rpm/issues/607

that upstream does not want to acknowledge.

IMO maintainer in this case is 100% right because all properties of the build env already can be described in with enough precision. Providing more details about build env will be duplicating current build dependencies.

Discussion about such cases should start from analyse of some case(s) when such details could help with some class of issues. Then someone should go to root cause that some exact failed/produced broken packages, and then (maybe) at the end some solution can be provided.
All those context details are missing in that issue ticket so (IMO) rpm maintainer had no even chance understand what caused that someone started thinking about storing such metadata in src.rpm.

BTW elfutils and glibc package EVR. This detail is already part of the koji root.log.
DEBUG util.py:556:   glibc                       x86_64 2.29.9000-17.fc31               build 3.9 M

Nevertheless some people forgets sometimes that spec syntax provides not only BuildRequire but BuildConflict token as well. With those two is possible with 100% accuracy describe build env properties.
That is all what rpmbuild needs to provide (IMO).

[tkloczko@domek SPECS.fedora]$ grep ^BuildConflict * | wc -l
38

Some packages source code build automation implements sometimes strange things. For example gawk is using libsigsegv only if autoconf is able to find it, and it is not possible to disable using it by provide configure parameter. However there is only handful of such cases and it is easier to fix those packages source code build automation than designing rpm extensions to handle such cases straight on packaging layer.

Uniformity below packaging layer should be our real goal .. this why when I see that in git repos someone is using some strange tagging convention like replace dots by underscores or putting build automation deep below project root directory (examples: recently introduced meson and cmake files in lz4 and zstd) I'm always trying gently ask maintainers to change this to implement and use those bits in kind of StandardWay(tm).
All because it makes packaging easier with virtually no costs on layer below.

Other issue is that as Fedora keeps only last versions/releases of all packages and even if someone would be storing full list of all installed packages in build env in koji gut it will have very limited abilities to help with something as it is not possible quickly reassembly from scratch exactly the same build env out of the available packages.

So question which only left from this branch of the discussion is:
What was the exact initial impulse which pushed someone to idea of storing full build env properties in src.rpm?
IMO someone have been only thinking that this could solve something (that someone had only incorrect impression that it would help with something).

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
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

[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