Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Aptly: Owning Your Debian Distribution

aptly.info

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Aptly: Owning Your Debian Distribution

#31

Post by robinson-wall »

qwerta wrote: post #23
hosay123 wrote: post #14

Earlier quoted context omitted.

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.

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.

Re: Aptly: Owning Your Debian Distribution

#33

Post by smira »

icebraining wrote: post #30
qwerta wrote: post #23

Earlier quoted context omitted.

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.

DEB packages are very complicated 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. ¹ https://github.com/jordansissel/fpm

I use fpm to build aptly .deb packages, it is extremely simple to use compared to usual source package + build path.

This is a problem for Go programs, due to multiple unversioned (usually) dependencies on other Go libraries.

Re: Aptly: Owning Your Debian Distribution

#36

Post by smira »

helper wrote: post #34

We use deb-s3[1] to maintain a custom apt repository in s3. It supports signed release files and does all the hard work for you. [1]: https://github.com/krobertson/deb-s3

aptly can do more much more than just S3 publishing: for example snapshotting, combining packages from different sources.

Re: Aptly: Owning Your Debian Distribution

#38

Post by dima55 »

dzderic wrote: post #24

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.

man dput

Re: Aptly: Owning Your Debian Distribution

#39

Post by grosskur »

lamby wrote: post #35

https://apt-captain.readthedocs.org/en/latest/ Here's my solution to this. Love using .debs for distribution.

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:

https://www.packagelab.com/

Sort of like a cross between Launchpad and Travis CI. If anyone's interested in trying it out, I'd love feedback.

Re: Aptly: Owning Your Debian Distribution

#40

Post by ShawnMilo »

qwerta wrote: post #23
hosay123 wrote: post #14

Earlier quoted context omitted.

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.

A container. Not "a Docker." Docker is a tool for using containers via the LXC project.
Post reply on HN