https://bugzilla.redhat.com/show_bug.cgi?id=1680043 --- Comment #5 from Debarshi Ray <debarshir@xxxxxxxxxx> --- (In reply to Carl George from comment #2) > [ ]: Packages should try to preserve timestamps of original installed > files. > > Does meson do this? Yes. [rishi@kolache toolbox]$ meson --prefix=/opt builddir && ninja -C builddir && ninja -C builddir install The Meson build system Version: 0.49.1 Source dir: /home/rishi/devel/toolbox/git/toolbox Build dir: /home/rishi/devel/toolbox/git/toolbox/builddir Build type: native build Project name: toolbox Project version: 0.0.6 ... ... Installing /home/rishi/devel/toolbox/git/toolbox/toolbox to /opt/bin [rishi@kolache toolbox]$ ls -lrt toolbox -rwxrwxr-x. 1 rishi rishi 24895 Mar 1 10:04 toolbox [rishi@kolache toolbox]$ ls -lrt /opt/bin/toolbox -rwxr-xr-x. 1 rishi rishi 24895 Mar 1 10:04 /opt/bin/toolbox [rishi@kolache toolbox]$ date Fri Mar 1 11:53:10 CET 2019 [rishi@kolache toolbox]$ > It seems that all meson is doing is installing the upstream toolbox script at > /usr/bin/toolbox. Why not just use the install command for this and avoid > the meson build requirement? That would be almost like coming up with an ad hoc build system. :) It's true that placing the toolbox script in the right location is the most important thing that we need to do. However, there are a number of other secondary items on the list: * Make it easy for passers-by and new contributors approaching the project to quickly try it out. A well known build system that's a de-facto standard is a lot more approachable than an ad hoc set of scripts. Just like we are still using Git, even though we are unlikely to use all the bells and whistles to manage the development of a single shell script. * What is today just a single shell script is unlikely to remain so in the near future. For example, just the inclusion of a set of manual pages is going to add more work that would need to be done. Then somebody will ask for a build flag to make those optional. Not to mention on-going work that's a lot more complex than scripts and man pages: https://github.com/owtaylor/fedora-toolbox/tree/toolboxd * Even though it's not an immediate concern today, using a well understood build system helps in conforming to things like the Build API (https://github.com/cgwalters/build-api) and is generally easier to plug into meta-build systems. * Not to mention various minutiae like supporting DESTDIR, preserving time stamps and so on. Given that a significant portion of our operating system has already replaced Autotools with Meson as the preferred build system, using Meson was the most obvious choice. This might, of course, be affected by significant changes to the project in future. eg., if the toolbox tool gets re-written in Rust or Go, then it might have a bearing on the build system. > https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Tags > > The Source0 url doesn't follow the guidelines for git tags, please change it > to: > > https://github.com/debarshiray/toolbox/archive/%{version}/%{name}-%{version}. > tar.gz > > or even better: > > %{url}/archive/%{version}/%{name}-%{version}.tar.gz Umm... why? The package is not referring to tarballs auto-generated by GitHub from Git tags. It's referring to the release tarballs explicitly listed against each release announcement: https://github.com/debarshiray/toolbox/releases In an ideal world, we would no longer be needing release tarballs and only operating with Git tags. Sadly, we aren't there yet because downstream distributors often work with tarballs. As long as that holds true, and generating a tarball is just a trivial 'ninja dist' away, I prefer to not rely on the auto-generated tarballs: * Avoids having to select one from the myriad of ways in which GitHub can auto-generate a tarball. eg., see how the URLs to the auto-generated tarballs (eg., https://github.com/debarshiray/toolbox/archive/0.0.6.tar.gz) on https://github.com/debarshiray/toolbox/releases differ from those given on https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Tags. * It's reassuring to use a tarball that was tested with 'ninja dist' by the person making the release. It's true that 'ninja dist' is very similar to the way GitHub auto-generates the tarballs, but regardless of the build system in play, the original principle still holds. * Various downstreams have a slight preference for non-auto-generated tarballs. eg., https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Services says: "If the upstream does create tarballs you should use them as tarballs provide an easier trail for people auditing the packages." * It avoids a needless dependency on the GitHub infrastructure. Or did I completely misinterpret your concern? -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx
