
Gittup, a Linux distro on top of Git - traverseda
http://gittup.org/gittup/
======
traverseda
I thought this was a pretty useful project for embedded work, and despite it
being a few years old I'd never heard of it.

The documentation is a bit... eclectic.

Tup is a build system that keeps track of what files a command accesses. So if
you run make from tup, it can look at every file your makefile reads from, and
re-run make if any of those files change. Not that useful, in that example,
but when you have it run gcc to make each source file instead, it can
automatically rebuild just the files that need to be rebuilt.

Building on top of that, they've set up a git repo with the appropriate
"tupfiles" (makefiles) to build linux and enough userspace to get by. It's not
so much a linux distribution as a build-system that can build an entire linux
distro from source.

The big difference between this and a normal build system is that all your
source files can be in the same tree as git submodules, and `tup upd` will
rebuild the _entire_ thing, only recompiling code who's source file or shared
libraries have changed.

I think it could be a pretty powerful system for a lot of projects, I'm
particularly interested in using it for building android images, and firmware
for ereaders.

~~~
xiaq
> It's not so much a linux distribution as a build-system that can build an
> entire linux distro from source.

Isn't a Linux distro largely defined by its packaging system, which in turn is
largely defined by how software is built from source?

~~~
kbenson
I wouldn't say a Linux distro package system is _largely_ defined by how
software is built form source, but it _can_ be, and it at least matters in all
cases.

I would say the package dependency tree is probably the most important,
defining feature of the package system. Second to that is delivery (and the
fact it's so high on the list is a testament to its importance, as I can
remember a time before it when we just had RPM and dpkg). Some package
managers also build form source, but that's a quirk of hose those operate, not
really a core requirement to delivering binaries to the end user.

Even FreeBSD's ports build system is largely defined be its dependency tree
and the rules they have in place to make fetching and building easy. Whether
binaries are delivered from it or source that's compiled locally is somewhat
transparent to the end user, other than the extra time it takes.

~~~
saghm
I think GP was saying that even the Linux package managers that deliver
binaries tend to build their own packages with a distro-specific build system
rather than just repackaging upstream binaries

~~~
kbenson
Ah, yes. It's entirely possibly I missed the point. :)

Although repackaging upstream can be a fuzzy concept. E.g. Ubuntu's early
days. They've always repackaged Debian packages, but I believe there was less
differentiation in the beginning, before Ubuntu has many of its own
initiatives and projects.

~~~
jldugger
Even now, Ubuntu releases start largely by forking debian unstable.

------
itomato
This is interesting. I have been wondering about the viability and communuty
interest in a service to enable subscription service for CI/CD systems at the
project level.

OSS maintainers don't have a unified mechanism to alert packagers of updates.

In place of a dirty hack to power IFTTT and Jenkins from fetchmail scripts
when there is an announcement, we could have intelligence and transparent
automation at the distro-level.

Maintainer patches a 0-day, and there's a mad scramble for everyone to patch,
test, package and publish.

I would rather not wait on Debian to release a distribution or be forced to
cherry-pick from Sid.

OpenSolaris and OpenBSD could have feature parity with Cygwin and Alpine.

We could have concurrent versioning, automation and container and filesystem-
based deployments become a little less risky.

Less focus on Vendor, more on Developer.

~~~
icebraining
Debian has vcswatch to keep track of updates. I think it only works if the
upstream repository keeps the Debian control files updated, but keeping track
of commits that update a generic CHANGELOG file should be simple.

That said, I don't think the vendor can be avoided unless you want to live on
the edge. If you're on a released version of a distro (otherwise, you wouldn't
have to cherry-pick from Sid), chances are you're not on the latest version of
the software, and the patch has to be backported by the distro maintainer to
version you are actually on.

------
dahart
I'll admit it started skeptical based on the headline, but reading the page, I
changed my mind, this seems like something worth at least trying to see what
package management feels like. It'd be pretty cool if something like this
could help smooth out package version incompatibilities.

In particular this idea is intriguing (and the honesty about not having tried
it is appreciated):

> Bisection!

> Let's say your compy86 is running fine, and then you update to get the
> latest, and something breaks. You can use git bisect across your _entire_
> linux distribution to find the commit that broke it.

> Note: It may not work across config changes, since tup doesn't automatically
> run 'oldconfig' when necessary.

> Note: I've never actually tried this, so we'll just assume it works.

------
mrmr1993
It seems like the distro name may violate the Git trademark policy [0]. From
[1]:

> ... you can't use the mark in a way that implies association with or
> endorsement by the Git project.

It might be worth checking with the Git project to see if they would approve
this use or find it within their allowed uses.

~~~
bmarkovic
Er.. Github, gitlab, gitkraken.. I don't think having git in the name is
enough to violate that clause

~~~
eat_veggies
Those all got written permission to use the name.

See a similar discussion from a few days ago:
[https://news.ycombinator.com/item?id=15991785](https://news.ycombinator.com/item?id=15991785)

------
wallnuss
My favourite sentence is: Note: I've never actually tried this, so we'll just
assume it works.

------
orblivion
Seems like a great way to help ease contribution. I've never used NixOS, but I
wonder how it would compare in this and other ways.

~~~
aidenn0
I've been using NixOS for a while now. There is a lot to be said for using nix
as a development tool &c, but in terms of a daily driver OS:

Upside: It really is the best of both worlds for binary/source distros. 99% of
the time it just downloads an archive and unpacks it, so it's just as fast to
install or upgrade as e.g. arch. On the other hand, patching software from
upstream takes seconds to do (not counting the unavoidable build time).

Downside: In order to accomplish the upside, it completely changes the
filesystem layout. "./configure; make; sudo make install" is basically
guaranteed to not work. To install software not in nix, you will be writing a
nix expression. There is a command to create an FHS compatible namespace that
works for e.g. Steam, but applications installed in there are second-class
citizens, so it's preferred to not do this for anything that can simply be
installed via a Nix expression.

~~~
ComputerGuru
Have you tried FreeBSD before? It ships with an awesome binary package manager
and a virtual tree of sources for all the packages in the package manager at
the same time. You can install the binary (sudo pkg install foo) or cd into
the source dir, fetch the sources, patch on a whim, then “make” (even if the
project upstream does not use make) and install.

~~~
honr
I have used ports (if that is what you are referring to) albeit on a mac. It
is very basic, without any of the interesting properties that make nix
interesting. It essentially feels like a slightly improved "download &&
./configure && make && make install" script.

~~~
aidenn0
It does have a usable binary cache, which is absent from other source-based
systems _glances in portage 's direction_

------
jwilk
> I couldn't find actual version control repositories for ncurses

[https://github.com/ThomasDickey/ncurses-
snapshots](https://github.com/ThomasDickey/ncurses-snapshots)

This repo is generated by exporting from RCS(!):

[http://invisible-island.net/personal/git-exports.html](http://invisible-
island.net/personal/git-exports.html)

There's also an unofficial git repo, which is more useful IMO:

[http://ncurses.scripts.mit.edu/?p=ncurses.git;a=summary](http://ncurses.scripts.mit.edu/?p=ncurses.git;a=summary)

------
alsadi
Y U no ostree?

[https://ostree.readthedocs.io/en/latest/manual/introduction/](https://ostree.readthedocs.io/en/latest/manual/introduction/)

------
nemo1618
The example of modifying `ls` struck me as something that _ought_ to be
possible in any Linux distribution with minimal effort. Instead, we have a
situation where most people use binary packages, so the source isn't even
available to modify. And even if you run a source-based distro like Gentoo,
editing those sources by hand can still be quite intimidating. Version control
makes it easier to experiment fearlessly (although it's still possible to
brick your system...).

~~~
seiferteric
It's really not too hard on a Debian system to build a modified package. All
sources should be available if you have the src repos in your sources.list.
You just download the src package, modify, rebuild and install.
[https://wiki.debian.org/BuildingTutorial](https://wiki.debian.org/BuildingTutorial)

~~~
traverseda
Return 403 for me...

~~~
mschuster91
Long story short:

1\. uncomment the deb-src lines in /etc/apt/sources.list; if you do not have
these, simply copy each deb line and have it begin with deb-src.

2\. apt-get update

3\. apt-get source <packagename>

4\. cd <packagename>-<version>

5\. (do modifications here)

6\. dpkg-buildpackage -us -uc

7\. install the .deb packages in the parent directory with dpkg -i

Do note, this does not properly embed your modifications in a patch or
whatever, I haven't figured out how to do this and lose my mind at the same
time.

------
jwilk
> I couldn't find actual version control repositories for [...] nethack

[https://github.com/NetHack/NetHack](https://github.com/NetHack/NetHack)

------
chenglou
For a build system similar to Tup, check out
[http://physics.oregonstate.edu/~roundyd/fac/introducing-
fac....](http://physics.oregonstate.edu/~roundyd/fac/introducing-fac.html)

Explicitly inspired by the former, same build paradigm, doesn't use FUSE. Has
some neat git integrations. Doesn't work on macOS/Windows yet though.

One funny feature that falls from the design is that you can just keep running
& failing a fac build, and it'll nudge you toward the correct build.

------
JepZ
To me this looks very similar to running a source based distro
(Gentoo,Exherbo,...) with lots of packages using git as a fetch method (Gentoo
uses the -9999 version suffix, Exherbo calls them scm packages).

Can anybody tell me _when_ I should use gittup instead? Is it just a matter of
size? Is rebuilding significantly faster with gittup due to the automatic
rebuilding?

I mean to me it looks that gittup has some serious limitations in its current
state (e.g. no 'make') while the others are full blown linux systems.

------
Too
Isn't this similar to yoctos bitbake? A bunch of package repos with a small
build combiner on top.

I'm also curious how else would you do it? The article make it sound unique
but this seems like the obvious solution, at least conceptually. How do other
distros manage and build their packages?

------
ericfrederich
Seems like it might be useful in creating a Docker image from source.

------
beejiu
Is this style of package management not what (broadly speaking) differentiates
BSD from Linux?

~~~
krylon
All the BSD systems[1] have had binary packages (at least optionally) for a
while now. On OpenBSD, while the ports tree is still there when needed, the
recommended way is to use binary packages.

[1] I am not entirely certain what the situation on DragonflyBSD is, I have
not touched it in a long time.

------
undoware
So.. 'tup' means something, uh, specific, in certain vernacular Englishes.

------
avinassh
Any reason why the GitHub repos are under an user account but not an org?

[0] - [https://github.com/gittup](https://github.com/gittup)

------
unixhero
Cool.

But why Linux kernel v2.6?

~~~
traverseda
It looks like it's an ancient half-abandoned project. Hopefully some people
here take an interest and breath a bit more life into it.

------
juanmirocks
Good idea. Reminds me of hombrew in macOS

------
mirceal
stopped reading at modules. I think this is an interesting ideas, but if one
would seriously consider this, this is a disaster waiting to happen.

------
HumanDrivenDev
Sounds good - can it run a decent VCS though, like mercurial?

