On Thursday 12 of March 2020 03:22:10 Michele Calgaro via trinity-devel
wrote:
> On 2020/03/12 01:50 AM, Sl�vek Banko wrote:
> > Hi all,
> >
> > as you probably know, if tdelibs are compiled with elf editor support
> > (WITH_ELFICON), the application icon, TDE information and git
> > repository information are embedded into libraries and binaries during
> > CMake build.
> >
> > This data, on the one hand, provides user convenience - better to see
> > the application icon than the general binaries icon. On the other
> > hand, they provide information to developers - for example, when
> > reporting creashes.
> >
> >
> > It is possible that you have also heard about the activity
> > Reproducible builds, which seems to us as a very good idea. See:
> >
> > https://reproducible-builds.org/
> > https://wiki.debian.org/ReproducibleBuilds
> >
> >
> > Currently, the metadata that are embedded has a Compilation Date/Time
> > entry. This is set to the current date and time at the time of
> > building the binary package. And this is a problem because it makes it
> > impossible to achieve reproducible builds.
> >
> > My suggestion is that next to the ".tdescmmodule" and
> > ".tdescmrevision" files we could have a ".tdescmdatetime" file
> > containing the git commit date and/or a ".tdepackagedatetime" file
> > containing the date the source package was created for distribution.
> > For embedded metadata, this fixed time would be used instead of
> > variable time.
> >
> > What is your opinion?
> >
> > Cheers
>
> Hi Slavek,
> glad that you have brought up this issue, since it is something I have
> experienced several times when checking the "drop automake" PR in the
> last few months.
> I also feel it is good to have reproducible builds. We already have the
> ".tdescmmodule" and ".tdescmrevision" which contains the git commit hash
> the package was build from. Nevertheless we are missing the
> tde-packaging hash in those files.
> Rather than having too many .tdescmXXXXX files, I propose we use a
> single .tdegitinfo file which includes module name, repo git hash and
> packaging repo hash.
> I don't see any need for any date in the package once we have the git
> hash info.
>
> Cheers
> Michele
>
Thank Michele, it is a good idea that instead of many files we can
consolidate git repository information into one file. I will prepare
patches / pull-requests in this sense.
Since the tde-packaging repository information and package information for
each distribution are independent, a separate package information file
will be required.
At the same time, git hash for tde-packaging is not enough for us, because
there is also interesting information about the distribution. In addition,
here can be forced rebuild without any changes in the git repositories -
as an example here is the 'libr' with dependency on binutils. Therefore,
it is still useful for us information about date+time and/or the version
of the package for a specific distribution.
Cheers
--
Sl�vek
Attachments: