10 ms·

Gittup, a Linux distro on top of Git

171 points by traverseda 9y ago

traverseda 9y ago
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 9y ago
  > 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?
  - traverseda 9y ago
    The big difference being that in order to get any real benefit you can't use upstream's build system, you need to use tup. I'd say it's not a linux distro yet.
    - ComputerGuru 9y ago
      I would say that’s definitely a huge benefit to the end users (though not the maintainers, that’s for sure) as “one build system to rule them all” is pretty much the dream, right? Presuming tup is good, of course. I played with it but I hated the fuse dependency and ended up switching to meson (though I despise the build-time python dependency, see [0]) for cross-platform projects and plain jane gmake or pmake Makefiles for others. I also hand code ninja build files for stuff that’s not too crazy and platform dependent, basically for things that gulp would normally be in control of.
      - DSMan195276 9y ago
        I really wanted to like tup, but I feel like it's just missing to many 'basic' things, along with being a bit annoying to setup and use. The big thing for me is that there is no `tup clean`, and also no way to create phony targets or multiple targets like with `make` - and they're not excluded because of complexity reasons, but because they just don't think it should be the job of the build system [0]. Which, they might be right, but if I can't actually replace my full Makefile's with Tupfiles, but instead have to replace it with Tupfiles + Makefile/shellscripts/installscripts/etc. then Tup is a lot less appealing to me. This is especially an issue since the scripts have no way of accessing the Tup information. With that said, I was curious how this project got around the 'install' problem, but it seems like they were largely able to just side-step the issue. They build an `initrd` from tup, and the `initrd` Tupfile copies all of the compiled executables into their proper folders before generating the `initrd`. So the projects themselves can't install themselves directly onto a system. [0] https://groups.google.com/d/msg/tup-users/Kxw1nnXK12o/my4IYt8OnzsJ https://groups.google.com/d/msg/tup-users/Kxw1nnXK12o/my4IYt...
        ComputerGuru 9y ago
        I agree with you, it's not there yet. It's the same problem over and over again with all these Make alternatives: close but if only xxx or if only not yyy. I agree that the installation approach is a total copout, I would have hardlinked all the files from their installation destination to the build artifacts. (presuming state is intended to be thrown away on rebuild.)
  - kbenson 9y ago
    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 9y ago
      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 9y ago
        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 9y ago
        Even now, Ubuntu releases start largely by forking debian unstable.
- equalunique 9y ago
  Page says it's only for x86, but hopefully this will be extended to other architectures. :D
ericfrederich 9y ago
Seems like it might be useful in creating a Docker image from source.
nemo1618 9y ago
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 9y ago
  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 9y ago
    Return 403 for me...
    - mschuster91 9y ago
      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.
- traverseda 9y ago
  It could go a long way towards getting people involved in FOSS systems development. I think you could avoid a lot of those bricking issues using btrfs snapshots.
  - 9y ago
unixhero 9y ago
Cool. But why Linux kernel v2.6?
- aidenn0 9y ago
  Because that was current the last time the kernel package was updated?
- traverseda 9y ago
  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.
- ComputerGuru 9y ago
  The entire source tree is based off of git submodules and an automatic build system, right? I wonder what would happen if you ran “git submodule —update” (presuming the submodules point to master, though I am unsure if that functionality was around in git when this was published) and then tried to build it with tup.
- jwilk 9y ago
  The article appears to be from 2012: $ curl -Is http://gittup.org/gittup/ | grep ^Last-Modified: Last-Modified: Fri, 23 Mar 2012 23:17:45 GMT
dahart 9y ago
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.
orblivion 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
alsadi 9y ago
Y U no ostree? https://ostree.readthedocs.io/en/latest/manual/introduction/ https://ostree.readthedocs.io/en/latest/manual/introduction/
avinassh 9y ago
Any reason why the GitHub repos are under an user account but not an org? [0] - https://github.com/gittup https://github.com/gittup
juanmirocks 9y ago
Good idea. Reminds me of hombrew in macOS
grondilu 9y ago
Interesting idea. I'd love to read what package maintainers think about this. Would it be completely ridiculous to consider this method as a replacement for all the various package management systems of the major linux distributions?
mrmr1993 9y ago
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.
- Shoothe 9y ago
  I agree. Usually names in format XY where X is a trademark are considered infringing. See several cases of projects named docker-something or Windows Subsystem for Linux, a name that technically doesn't make sense but "for X" names are usually OK.
- bmarkovic 9y ago
  Er.. Github, gitlab, gitkraken.. I don't think having git in the name is enough to violate that clause
  - eat_veggies 9y ago
    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
- jwilk 9y ago
  404 Footnote Not Found
  - mrmr1993 9y ago
    Looks like the gremlins ate them, sorry! [0]: https://git-scm.com/trademark https://git-scm.com/trademark [1]: https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw@sigill.intra.peff.net/ https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw...
- trendia 9y ago
  Does GitHub have to pay a fee to use Git in their name?
beejiu 9y ago
Is this style of package management not what (broadly speaking) differentiates BSD from Linux?
- krylon 9y ago
  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.
wallnuss 9y ago
My favourite sentence is: Note: I've never actually tried this, so we'll just assume it works.
mirceal 9y ago
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 9y ago
Sounds good - can it run a decent VCS though, like mercurial?
- traverseda 9y ago
  No reason it couldn't use any VCS system you wanted, better or not.
itomato 9y ago
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 9y ago
  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.
- andrey_utkin 9y ago
  > OSS maintainers don't have a unified mechanism to alert packagers of updates. Gentoo developers have http://euscan.gentooexperimental.org/ http://euscan.gentooexperimental.org/ . Quite some automation is on the way to come soon.
jwilk 9y ago
> 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
jwilk 9y ago
> I couldn't find actual version control repositories for [...] nethack https://github.com/NetHack/NetHack https://github.com/NetHack/NetHack
undoware 9y ago
So.. 'tup' means something, uh, specific, in certain vernacular Englishes.
JepZ 9y ago
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.
chenglou 9y ago
For a build system similar to Tup, check out http://physics.oregonstate.edu/~roundyd/fac/introducing-fac.html http://physics.oregonstate.edu/~roundyd/fac/introducing-fac.... 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.
Too 9y ago
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?

171 points by traverseda 9y ago

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 9y ago
> 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?
- traverseda 9y ago
  The big difference being that in order to get any real benefit you can't use upstream's build system, you need to use tup. I'd say it's not a linux distro yet.
  - ComputerGuru 9y ago
    I would say that’s definitely a huge benefit to the end users (though not the maintainers, that’s for sure) as “one build system to rule them all” is pretty much the dream, right? Presuming tup is good, of course. I played with it but I hated the fuse dependency and ended up switching to meson (though I despise the build-time python dependency, see [0]) for cross-platform projects and plain jane gmake or pmake Makefiles for others. I also hand code ninja build files for stuff that’s not too crazy and platform dependent, basically for things that gulp would normally be in control of.
    - DSMan195276 9y ago
      I really wanted to like tup, but I feel like it's just missing to many 'basic' things, along with being a bit annoying to setup and use. The big thing for me is that there is no `tup clean`, and also no way to create phony targets or multiple targets like with `make` - and they're not excluded because of complexity reasons, but because they just don't think it should be the job of the build system [0]. Which, they might be right, but if I can't actually replace my full Makefile's with Tupfiles, but instead have to replace it with Tupfiles + Makefile/shellscripts/installscripts/etc. then Tup is a lot less appealing to me. This is especially an issue since the scripts have no way of accessing the Tup information. With that said, I was curious how this project got around the 'install' problem, but it seems like they were largely able to just side-step the issue. They build an `initrd` from tup, and the `initrd` Tupfile copies all of the compiled executables into their proper folders before generating the `initrd`. So the projects themselves can't install themselves directly onto a system. [0] https://groups.google.com/d/msg/tup-users/Kxw1nnXK12o/my4IYt8OnzsJ https://groups.google.com/d/msg/tup-users/Kxw1nnXK12o/my4IYt...
      - ComputerGuru 9y ago
        I agree with you, it's not there yet. It's the same problem over and over again with all these Make alternatives: close but if only xxx or if only not yyy. I agree that the installation approach is a total copout, I would have hardlinked all the files from their installation destination to the build artifacts. (presuming state is intended to be thrown away on rebuild.)
- kbenson 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        Even now, Ubuntu releases start largely by forking debian unstable.
equalunique 9y ago
Page says it's only for x86, but hopefully this will be extended to other architectures. :D

ericfrederich 9y ago

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

nemo1618 9y ago

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 9y ago
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 9y ago
  Return 403 for me...
  - mschuster91 9y ago
    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.
traverseda 9y ago
It could go a long way towards getting people involved in FOSS systems development. I think you could avoid a lot of those bricking issues using btrfs snapshots.
- 9y ago

unixhero 9y ago

Cool. But why Linux kernel v2.6?

aidenn0 9y ago
Because that was current the last time the kernel package was updated?
traverseda 9y ago
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.
ComputerGuru 9y ago
The entire source tree is based off of git submodules and an automatic build system, right? I wonder what would happen if you ran “git submodule —update” (presuming the submodules point to master, though I am unsure if that functionality was around in git when this was published) and then tried to build it with tup.
jwilk 9y ago
The article appears to be from 2012: $ curl -Is http://gittup.org/gittup/ | grep ^Last-Modified: Last-Modified: Fri, 23 Mar 2012 23:17:45 GMT

dahart 9y ago

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.

orblivion 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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 9y ago

alsadi 9y ago

Y U no ostree? https://ostree.readthedocs.io/en/latest/manual/introduction/ https://ostree.readthedocs.io/en/latest/manual/introduction/

avinassh 9y ago

Any reason why the GitHub repos are under an user account but not an org? [0] - https://github.com/gittup https://github.com/gittup

juanmirocks 9y ago

Good idea. Reminds me of hombrew in macOS

grondilu 9y ago

Interesting idea. I'd love to read what package maintainers think about this. Would it be completely ridiculous to consider this method as a replacement for all the various package management systems of the major linux distributions?

mrmr1993 9y ago

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.

Shoothe 9y ago
I agree. Usually names in format XY where X is a trademark are considered infringing. See several cases of projects named docker-something or Windows Subsystem for Linux, a name that technically doesn't make sense but "for X" names are usually OK.
bmarkovic 9y ago
Er.. Github, gitlab, gitkraken.. I don't think having git in the name is enough to violate that clause
- eat_veggies 9y ago
  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
jwilk 9y ago
404 Footnote Not Found
- mrmr1993 9y ago
  Looks like the gremlins ate them, sorry! [0]: https://git-scm.com/trademark https://git-scm.com/trademark [1]: https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw@sigill.intra.peff.net/ https://public-inbox.org/git/20170202022655.2jwvudhvo4hmueaw...
trendia 9y ago
Does GitHub have to pay a fee to use Git in their name?

beejiu 9y ago

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

krylon 9y ago
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.

wallnuss 9y ago

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

mirceal 9y ago

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 9y ago

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

traverseda 9y ago
No reason it couldn't use any VCS system you wanted, better or not.

itomato 9y ago

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 9y ago
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.
andrey_utkin 9y ago
> OSS maintainers don't have a unified mechanism to alert packagers of updates. Gentoo developers have http://euscan.gentooexperimental.org/ http://euscan.gentooexperimental.org/ . Quite some automation is on the way to come soon.

jwilk 9y ago

> 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

jwilk 9y ago

> I couldn't find actual version control repositories for [...] nethack https://github.com/NetHack/NetHack https://github.com/NetHack/NetHack

undoware 9y ago

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

JepZ 9y ago

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.

chenglou 9y ago

For a build system similar to Tup, check out http://physics.oregonstate.edu/~roundyd/fac/introducing-fac.html http://physics.oregonstate.edu/~roundyd/fac/introducing-fac.... 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.

Too 9y ago

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?