docker brought back the frenzy of delivering software in a tarball just like slackware in the past. Long live patrick volkerdig and tar -zxvf ... -C / !
Are tarballs obsolete?
11–20 of 85 posts
Re: Are tarballs obsolete?
#12docker brought back the frenzy of delivering software in a tarball just like slackware in the past. Long live patrick volkerdig and tar -zxvf ... -C / !
Pro Tip: You don't need the dash. That's how old-school tar is!
Re: Are tarballs obsolete?
#13Tarballs versus DVCS appears to be a false dilemma. They're independent mechanisms. The more proper question to ask here is "Are tarballs obsolete for distributing source code?".
Re: Are tarballs obsolete?
#14The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the documentation. The user of the distributed tarball is fully capable of re-running these steps, but they have become optional.
This is a fact often forgotten when projects switch to github and just start using the automated release tarballs github will make from the repo.
Re: Are tarballs obsolete?
#15The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the docume…
Yes! Thank you for explaining this. I don't think a lot of people realize what makes up a good release tarball.
Re: Are tarballs obsolete?
#16Absolutely not; there are a myriad of reasons to prefer tarballs over Git: - Offline use - Permission restrictions (Internal git networks) - True-persistent versioning (Can always delete and update a tag), no external tools needed to download - Can restrict extra garbage that may not be need to be shipped - Etc.
> Offline use
Tarballs are just as offline as git repositories...
> Permission restrictions (Internal git networks)
What?
> True-persistent versioning (Can always delete and update a tag)
Why is that of concern regarding "tarballs vs git"? If anything it's a win for git.
> Can restrict extra garbage that may not be need to be shipped
Only valid point you presented, and it's better discussed elsewhere in this thread.
Re: Are tarballs obsolete?
#17The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the docume…
Exactly.
Many web tool chains involve pulling from external repositories such as npm, bower or even github itself. If one of these are down you cannot deploy your application.
Even better many packaging systems such as npm or setuptools allow you and library maintainers to specify a flexible version numbers for your dependencies. If during the course of your build, test and deploy chain one of these dependencies changes your application could break through no fault of your own. You cannot rely on maintainers to not release breaking changes in minor versions, it happens all the time, intentionally or not.
Re: Are tarballs obsolete?
#18The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the docume…
This becomes more complex when distributions want to patch configure.ac or Makefile.am -- they need to patch the included Makefile.in files as well.
Trying to balance these two forces is the reasoning behind the AM_MAINTAINER_MODE flag.
These days, I prefer to simply use git archive for a tarball and make users run autogen.sh themselves.
See https://blogs.gnome.org/desrt/2011/09/08/am_maintainer_mode-... and the associated comments.
Re: Are tarballs obsolete?
#19The article seems to mean "tarballs are obsolete for source distribution", not obsolete on the whole.
> Here’s an advantage of the clone/pull distribution system; every clone is implicitly validated by its SHA1 hash chain.
Given that TLS does not consider SHA1 secure[1] anymore… I'm not sure that's an assumption I'd be making.
[1] in the sense that it's being rapidly deprecated; even if it doesn't trigger validation failures today, the fact that it will tomorrow is telling.
Re: Are tarballs obsolete?
#20Correct me if I'm wrong but doesn't a git clone involve downloading the project's entire git history as well as $CURRENT_VERSION? That seems a little excessive.
And what if you find a bug, and want to regress to a previous version?
What is so cumbersome about downloading a project's history?