Hello, I have been systemd user since version 38 and have followed the development ever since then. But, since the move to github, it has become extremely difficult to track commits via the web interface between releases now that "pull requests" are preferred method of contributing.
I guess main reason for that is that the commit time is left as the original author commited it to his fork. That makes some patches way in the past on the web interface, which makes me (or more people) think the patch was there since, for example, 220 instead of post 221 release. Now, this might be an issue with my limited git knowledge, but I don't think that's related to the web interface not showing the commits in the correct order between two release tags. So, my first question is: How do I get around this? Is there any sane way of me knowing which exactly commits happened between two release tags from the web interface? If not, is there any other method for achieving the same (from the git tree itself). I am also a maintainer of Linux From Scratch systemd edition, which is a book that guides an user to utilize an existing Linux system to build a new, minimal one from sources, while teaching the user about core packages build procedures and how the Linux system is put together. Another goal is to apply as few patches as possible to get it to work properly. That said, we only link to upstream sources and let the user download, extract and run the commands required to configure, build and install the package. The distribution includes about 60 source packages, each in format that includes package name and package version in its tarball name. Now, to the problem. Starting with systemd-222, github tarballs are preferred and the downloaded tarball is in format v222.tar.gz, which is, due to what I said above, unnacceptable for the book to refecence. (Imagine everyone went the same path and provided tarballs with version in it - it would become a mess and impossible to distinguish between different source packages). I wasn't subscribed to the mailing list at the time notice was sent about using github-generated tarballs, so I couldn't speak up and I apologize for that. But, now that systemd-222 has been released, I have started looking at how to integrate the 222 release into Linux From Scratch systemd edition. The first idea was to download the unmodified tarball to our server and simply rename it to systemd-221.tar.gz and use that. The idea went down since the tarball doesn't include autotools generated files such as configure and Makefile.in. Due to minimalism of the distribution, to utilize ./autogen.sh on a Linux From Scratch system would require adding additional packages to the core distribution just for that sake, which is also unnaceptable (see the libgcrypt issue posted recently and I don't want to mention python). With that idea down the toilet, I went: wth, I can create a distribution tarball myself and host it the same way I'd host a renamed tarball and reference it from our book. I fired up configure, make dist and to my surprise, generated tarball contents didn't match ones available in the 221 tarball. I discovered a commit 2c8849add40805256156a36d7ef8c54cf019e29e by Kay Sievers which literally broke the make dist target. A lot of += were removed, making a target that appears more than once redefine itself each time instead of appending the new lines to an already existing target which made make dist ommit a few essential files in a tarball. Another major issue for our distribution is removal of generated man pages and html documents from the distribution tarball, which would leave our users without documentation on a default install, given that the distro itself (again, due to its minimalism) doesn't include the necessary tools to build them from source. Previously, even though those tools weren't present, the pre-generated man pages and html docs installed nicely. Third issue in the mentioned commit, although not important for us (and I doubt anyone in that matter) is inclusion of non-distribution related files in the tarball, such as autogen.sh, the various dotfiles, several developer-only related tools, etc. IMO, those shouldn't be part of a distro tarball (but as I said, it isn't an issue, just a random thought). And yes, I'm aware that the commit is there to sync the git archive and make dist targets, but it just breaks too much for too little gain - the git archive target generates more broken tarball and with more useless stuff than the actual make dist target. Now, that you know my story (I'm not sorry for the long post by the way), what do you advise me to do in the case of tarball distribution? Do I really have to maintain a patch to generate a non broken tarball from now on? -- Note: My last name is not Krejzi.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
