I just finished putting together an aptly repo system on Friday, with a 'testing', 'staging', and 'production' repo. Buildbot dumps unsigned builds into testing, and a meatspace process copies those builds into staging or production when appropriate.
Aptly is a godsend to people who want to run .deb repos, as previously the software was basically "run a full mirror" or "sucks to be you". Jordan Sissel (fpm author) once remarked that 'there is a lot of silly ceremony in managing .debs'. We were previously using reprepro, which was alright, but had the glaring flaw of only allowing one version of a package to live in the repo. No easy rollbacks or machines on different versions there.
Aptly is really flexible, and although it does have some corner cases or slightly unintuitive behaviour (to me), it has excellent documentation and is in heavy development. Kudos to you, smira.
Looks awesome! I'm actually working on a SaaS product along similar lines. Right now it can build RPM and Debian packages directly from GitHub sources:
For anyone who has ever battled with maintaining their own apt/yum repos, this seems like a godsend.
The most-used tools for getting a package into your repo involve scp'ing the file to the repository server and running a command to update its index. It's nice to have a proper toolset to do this, but it's too bad I spend most of my time with YUM nowadays.
This is really cool. If you're using Ubuntu or Debian as your base OS then you really should be managing your software with something like this and offloading your deployment to it as well. The benefits of a setup like that are dead-simple rollbacks and deployment scripts.
Aptly is a repository manager, it works in terms of tightly defined package versions and dependencies.
Docker is for deployment, it works in terms of graphs of filesystem images. The tools do slightly overlap in use case, but they operate in entirely different domains.
It wouldn't be unreasonable to mix both in the same project, but there is no hard rule for when this would be appropriate.
I think I will stick with a Docker. DEB packages are very complicated and this tool does not really handle dependency conflits and so on that well. Plus it does not work with RPM and other packages systems.
Not really, it's just a tar file with some metadata. Using fpm¹, making packages from a directory is extremely simple. I've been building internal packages from our different components, and the build script only has three or four lines. And besides, even Dockerfiles often use apt/yum.
I'm currently working on transitioning to a Docker-based infrastructure. My existing system builds .debs and pushes them to an internal repository (reprepro rather than aptly because aptly was in its infancy when I built it).
I'm not going to be building .debs for installation inside Docker containers (turtles all the way down) but I would still consider something like aptly for storing and managing any obscure dependencies that my applications might require, and for maintaining a mirror on the local network to speed up image builds.
This sounds really nice. I've been using apt as a deployment mechanism not unlike the use-cases describe. While the whole thing's been rock solid, the repo management could do with a cleaner interface. Looking forward to giving it a go!
Would be sensible, if only the installation procedure didn't cluelessly combine downloading source with compiling it. Hey, some people want to build binary packages out of the code out there!
The issue with this setup is that you can't define "services" from within Nix without NixOS. A service basically ties together a set of packages and configuration and puts them in systemd.
At the moment, you'd have to use an external configuration management system for actually defining your systemd services, etc.
I deploy a couple things via Nix package manger to non-NixOS systems, and I manage my own system configs, etc. within Nix. My "external configuration management system" is pared down to a small script that symlinks everything in a directory into another directory (such as /etc/init).
One thing missing from Nix is ability to store passwords and the like in the nix store, and from what I understand this applies to NixOS as well as using Nix outside NixOS. For example, every file in the nix store is world readable.
NixOps gets around this to some extent by allowing you to define keys to be copied to /run/keys when configuring a remote system. They thus never touch the remote store.
Half of the posts in this thread are about the author's English. I know that clear communication and constructive feedback on one's command of a language is good, but... come on.
It's just article-dropping; get to know a few Eastern Europeans well and you might start doing it yourself.
One of my old bosses was Bosnian Croat, dropped articles like crazy, and added them in the wrong places. She would run her important emails by me for article-fixing before sending them. She was still smarter than me and better at her job than I was. Turns out that mastery of the arbitrary rules of English article placement and choice isn't a very good indicator of intelligence or competence.
Our author seems to consistently make the same mistake: there's a distinct lack of articles in the writing. Sprinkle some in, and things start to make sense:
> [A] Linux distribution is [a] well-tested collection of packages
> we would like to have [an] internal mirror of [a] package repository
> some packages are missing in [the] official distribution
> we would like to own [a] package repository, that is to have [a] package repository
> There are many tools to create [a] mirror of [the] Debian package repositories
… and so on. At any rate, this consistency suggests (to me, at least) that he's probably not a native English speaker; in fact, the writer is almost certainly Russian. There's a link to a sponsor, which has a Russian phone number, and if you click around enough, you can find his CV quite easily.
Not everyone on the Internet speaks English, however, enough people do that I could easily see it being beneficial to put your content in English. Who knows?
For some reason, native speakers of Slavic languages who learn English as a second language, often omit some prepositions in English. It's 100% understandable, but I'm really curious what's the actual reason why this happens.
Funny thing is, when we(native speakers of Slavic languages) read such english text with omitted articles we do understand it as intended and often we do not even realize that it's missing something.
It probably has something to do with out languages having more grammatical cases than English (which, arguably, has two, though it's possible to only use one).
Grammar aside, I'd say the plural feels more natural in this case:
"Linux distributions are well-tested collections of packages …"
But for singular you need to qualify "Linux distribution":
"A Linux distribution is a well-tested collection of packages …"
And I'd probably say "by a vendor" instead of "by the vendor" as it's not clear you're talking about a specific vendor.
Also, the "a" is wrong in this:
"There’s a support for …"
This should be: "There is support for …", in other words: "Support exists for …". Support is non-countable (like water, peace or terrorism) in English.
As a rule of thumb:
* if it's non-countable, just leave it bare: "I bought water", "It has support", "This is murder".
* if you're referring to a specific instance of something the audience knows about or you're going to qualify, use "the": "I bought the house [I previously told you about]", "I shot the gopher that kept digging up my lawn".
* otherwise use "a": "I bought a house" (this is news to you), "I ran over a cat" (if you say "the cat", the listener would instantly think "which one?").
In English (en-gb) colloquialism "I ran over the cat" would be perfectly fine as "the cat" is understood to mean "our/my cat". "Your dinner's in the dog", "I locked the keys in the car", et cetera.
Similarly in a sentence like "Why don't you and the family come up to the house sometime for tea.". "The house" substitutes for "our house". Now all you need to work out is whether tea is afternoon tea, a cup of tea, or an evening meal and if the offer is sincere. I gather the response is supposed to be "That would be lovely." rather than actually trying to arrange the proffered social meeting.
Sure, but presume neither the speaker nor the recipient owns a cat. Without an obvious context ("the cat"? what cats could we both know of?), it's not entirely clear.
Saying "the" instead of "a" generally assumes a context that has either been established before during the conversation or outside of it.
Imagine a stranger telling you they "accidentally killed the koala". You'd be confused. Not that strangers telling you about exotic animals they accidentally killed wouldn't be confusing enough.
I wasn't disagreeing I was just adding extra depth to what you said. Yes it's not entirely clear language, that's why it's colloquialism rather than being adopted as proper speech/writing.
Like you say "the item" means there should be an antecedent [previous mention].
If someone said they'd "killed the koala" I'd assume it was a euphemism for something!!
English has a countable "support" - it can be used to refer to several physical objects in various structural contexts (architecture being one). That is not the sense in which it's being used here, though.
The missing article at the start of the sentence makes it very hard to decipher if you're talking about Linux distributions in general or a specific one. "A Linux distrubution is ..." is probably what you intended to say, but I'm not sure.
Aptly is a godsend to people who want to run .deb repos, as previously the software was basically "run a full mirror" or "sucks to be you". Jordan Sissel (fpm author) once remarked that 'there is a lot of silly ceremony in managing .debs'. We were previously using reprepro, which was alright, but had the glaring flaw of only allowing one version of a package to live in the repo. No easy rollbacks or machines on different versions there.
Aptly is really flexible, and although it does have some corner cases or slightly unintuitive behaviour (to me), it has excellent documentation and is in heavy development. Kudos to you, smira.