[systemd-devel] About github repo and release tarball change

Armin K. krejzi at email.com
Thu Jul 9 02:43:01 PDT 2015


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150709/571c978a/attachment.sig>


More information about the systemd-devel mailing list