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.
https://kojipkgs.fedoraproject.org//packages/elfutils/0.176/2.fc31/data/logs/x86_64/root.log contains line:
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).
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
