I see. I had a quick look and this seems to be for the man page, which includes .. command-output:: spack spec netcdf-c. This makes the build non reproducible as it apparently also contains also the CPU type. It also doesn't look great to have Dummy in there:
Its a build artifact in the documentation of the package, but imho on the same level as rpm -q --info will also tell you on which host the package was build.
Having dummy in here is really not great and I will try to update that spack calls which should be possible as spack can be used for cross building and values for the architecture and OS can be given on the command line.
Still the change of /etc/os-release is important, as it might be called internally by spack.
N.B.
Will /etc/os-release stay or be replaced by /usr/etc/os-release in the future?
> Its a build artifact in the documentation of the package, but imho on the same level as rpm -q --info will also tell you on which host the package was build.
The big difference there is that the build host is part of the package metadata and not of the content. If the content doesn't change, the package is seen as identical and doesn't get published. This saves build time, repo space and avoids needless updates.
> Having dummy in here is really not great and I will try to update that spack calls which should be possible as spack can be used for cross building and values for the architecture and OS can be given on the command line.
Sounds good!
> N.B. Will /etc/os-release stay or be replaced by /usr/etc/os-release in the future?
There's /usr/lib/os-release already, but I expect /etc/os-release to be around for the forseeable future.
packages depending on dummy-release sounds dangerous to me, but I don't mind
We inject dummy-release into the buildroot for everything that has BuildRequires: distribution-release
If any package actually reads
VERSION_IDfrom/etc/os-release, it's just broken. Can you give an example?The submit of spack [https://spack.io/] failed as the doc package runs spack in the build process and spack itself reads out this information.
I see. I had a quick look and this seems to be for the man page, which includes
.. command-output:: spack spec netcdf-c. This makes the build non reproducible as it apparently also contains also the CPU type. It also doesn't look great to haveDummyin there:$ spack spec netcdf-c Input spec -------------------------------- netcdf-c Concretized -------------------------------- netcdf-c@4.7.4%gcc@10.2.1~dap~hdf4~jna+mpi~parallel-netcdf+pic+shared arch=linux-Dummy-sandybridge ^hdf5@1.10.7%gcc@10.2.1~cxx~debug~fortran+hl~java+mpi+pic+shared~szip~threadsafe api=none arch=linux-Dummy-sandybridge ^openmpi@3.1.6%gcc@10.2.1~atomics~cuda~cxx~cxx_exceptions+gpfs~java~legacylaunchers~lustre~memchecker~pmi~singularity~sqlite3+static~thread_multiple+vt+wrapper-rpath fabrics=none schedulers=none arch=linux-Dummy-sandybridge ^hwloc@1.11.11%gcc@10.2.1~cairo~cuda~gl~libudev+libxml2~netloc~nvml+pci+shared arch=linux-Dummy-sandybridge ^libpciaccess@0.16%gcc@10.2.1 arch=linux-Dummy-sandybridge ^libtool@2.4.6%gcc@10.2.1 arch=linux-Dummy-sandybridgeWhile I agree that this looks like a spack bug, I still don't mind having the dummy-release being more complete
Me neither
Its a build artifact in the documentation of the package, but imho on the same level as
rpm -q --infowill also tell you on which host the package was build. Having dummy in here is really not great and I will try to update thatspackcalls which should be possible asspackcan be used for cross building and values for the architecture and OS can be given on the command line. Still the change of/etc/os-releaseis important, as it might be called internally by spack. N.B. Will/etc/os-releasestay or be replaced by/usr/etc/os-releasein the future?> Its a build artifact in the documentation of the package, but imho on the same level as rpm -q --info will also tell you on which host the package was build.
The big difference there is that the build host is part of the package metadata and not of the content. If the content doesn't change, the package is seen as identical and doesn't get published. This saves build time, repo space and avoids needless updates.
> Having dummy in here is really not great and I will try to update that spack calls which should be possible as spack can be used for cross building and values for the architecture and OS can be given on the command line.
Sounds good!
> N.B. Will /etc/os-release stay or be replaced by /usr/etc/os-release in the future?
There's
/usr/lib/os-releasealready, but I expect/etc/os-releaseto be around for the forseeable future.