Live data from Hacker News

Are tarballs obsolete?

esr.ibiblio.org

71–80 of 85 posts

Re: Are tarballs obsolete?

#71
post #14

The 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…

To provide a little more information: the standard Makefile target for generating tarballs is `dist` (which all GNU projects should implement). For those curious, go take a look at some of your favorite projects that implement this target and see what the resulting tarball may result in, versus the contents of the repository.

https://www.gnu.org/prep/standards/standards.html#Standard-T...

Re: Are tarballs obsolete?

#72
post #30

Earlier quoted context omitted.

> Why is that of concern regarding "tarballs vs git"? If anything it's a win for git. Git tags (and branches) are mutable. Tarballs technically are, but don't move around as much. Unless someone's being actively malicious, you can be confident that no-one's going to put new code in an old-versioned tarball.

The exact same can be said of git. You're reaching. Git has builtin verification of absolutely everything it holds (tags included) since it uses sha1 for objects and commit messages, and they include the previous state... so a point in a git tree in that way is a hell of a lot more immutable than a tarball.

Yeah, except you can change a tag and it is still verified.

Re: Are tarballs obsolete?

#73
post #31

No! Things like package managers and git, however pervasive, are agents and not the testable, serialized representation of data. Why wouldn't you make the same file set available as a single download via plain, old HTTP(S)? What's so hard about that? Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser? You CAN'T hash a tree of files quickly by ha…

> Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser? wget git clone What is the difference in learning curve ? > With a single file, available by HTTP, any platform can get to it, so if your machine dies, and you have to call a friend for help, and they don't use the same OS, they won't have to install a special tool, or hope an intervening thi…

> What is the difference in learning curve ?

Everyone knows how to use an http client and everyone has an http client. Most people do not know how to use git and most people do not have a git client. It's more of a vertical line than a curve.

Re: Are tarballs obsolete?

#74
post #21

Correct 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.

The article suggests that this is not a big deal anymore now that computers have more storage and networks have more bandwidth.

There are still a lot of networks that don't have enough bandwidth to make git trivial. Most home networks, it's going to turn a 5-second download into 60 seconds or more. Some networks, it's going to turn a 1-minute download into a half an hour.

Re: Are tarballs obsolete?

#75
post #68

Earlier quoted context omitted.

> Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser? wget git clone What is the difference in learning curve ? > With a single file, available by HTTP, any platform can get to it, so if your machine dies, and you have to call a friend for help, and they don't use the same OS, they won't have to install a special tool, or hope an intervening thi…

wget more like wget until you've done it enough times to remember it. Learning curve indeed.

You can generally replace

    
with

    tar -xf 

Re: Are tarballs obsolete?

#76
post #53

I am strongly in favour of tarballs for releases. Git tags can be moved, for example, so that's an extra thing to be careful about, if one is worried about reproducibility. http://yakking.branchable.com/posts/releases/ That's my write-up on the topic of making releases, from about a month ago.

Thanks for posting your blog post link. Having only published static websites, I've been curious about the release process and your notes provide some insight, especially the parts about signatures.

Re: Are tarballs obsolete?

#77
post #14

The 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…

I got bitten by this a couple of days ago - I wrongly assumed that tags on GitHub were identical to the tarballs offered on the project's website. Not so much, as it turns out: https://github.com/Tarsnap/spiped/issues/26

Re: Are tarballs obsolete?

#78
post #68

Earlier quoted context omitted.

wget more like wget until you've done it enough times to remember it. Learning curve indeed.

You can generally replace with tar -xf

    -x means extract

    -f means force
and my favorite to put in there is:

    -v for verbose
This shows you all of the files being processed, sometimes it can be really helpful to see. Try:

    tar -xvf 

Re: Are tarballs obsolete?

#79

I like tarballs. Speaking as a non-programmer who compiles things like Vim and Scrypt, it is nice to be able to download a release without having to install a VCS first.

Tarballs are also easier to attach to an email or to share with other computers :)

Re: Are tarballs obsolete?

#80
post #78

Earlier quoted context omitted.

You can generally replace with tar -xf

-x means extract -f means force and my favorite to put in there is: -v for verbose This shows you all of the files being processed, sometimes it can be really helpful to see. Try: tar -xvf

Actually, -f makes tar read from a file instead of stdin.
Post reply on HN