Show HN: OpenAPT first release – Automate your APT repositories layouts | Hacker News Reader

Show HN: OpenAPT first release – Automate your APT repositories layouts

github.com

22 pointsrmedaer16 comments

This looks awesome. I'll need to try this out. I've used aptly to create repos before. Here are my ansible scripts:

https://github.com/BigSense/vSense/blob/master/ansible/roles...

Publishing was kinda a nightmare:

https://github.com/BigSense/vSense/blob/master/ansible/roles...

It's still using the very old Jenkins pipelines (the server is gone now so none of that even works) and a config management system that's long dead. I desperately need to rewrite it and this looks like a good starting point for at least the deb repos!

Managing, organising and publishing APT repositories became a nightmare for us as well. That's why OpenAPT is alive.

It moves APT management from script paradigm to state description paradigm. Indeed with OpenAPT, you don't have to write command lines anymore but instead you describe the state you want to achieve. Just like Ansible does.

Btw, it's a brand-new project. If documentation is lacking, feel free to open issue(s). We will be happy to help you.

Nice!

A few years ago a coworker wrote a similar thing (https://github.com/queeno/aptlify).

Unfortunately it seems to be abandoned at this point, so I do hope your project gets the tracktion it needs!

My brain parses all caps ‘APT’ as ‘advanced persistent threat’.

In regards to the package manager, doesn’t OpenAPT imply a closed apt? Is that a thing?

What do you mean by "closed apt" ?

Exactly.

What is meant by “OpenAPT?”?

Understood! The name is inspired by "Open*" projects. For instance OpenAPI. The goal of this project is first to design a specification format for APT repositories like OpenAPI is doing for HTTP APIs.

I have to admit that it is not the best name ever. I'm "open" to any better proposal. Feel free to open an issue with the best meaningful name idea you have!

I think most people would be better off abandoning Apt or RPM and use containers, Snap, AppImage or switch to a distro like Arch/Alpine.

This notion is completely upside-down.

Distro packaging means that global teams of developers are backporting bug and security fixes all day, every day, and running them through massive CI systems that have been in existence for decades.

Containers are great for scaling, and terrible for software distribution. Done right, they need to be rebuilt daily to pick up the latest fixes in the underlying OS.

Snap and AppImage mean you're on the hook for care and feeding of every library you bring in, yourself.

Rolling distros mean that you need a staff to integrate all the changes that are happening with no cadence other than "apparently today's update broke X". More likely, it would be a team dedicated to "apparently Y has been broken for a week, we found the problem, we're trying to upstream it, but now service X relies on the new functionality, so we're doing a conference call with them tomorrow to find out if they can roll back that change."

> Distro packaging means that global teams of developers are backporting bug and security fixes all day, every day, and running them through massive CI systems that have been in existence for decades.

I said nothing against distros, but I said I preferred Alpine/Arch. If you look for these massive CI systems, they don't exist for any retail-based distro like Ubuntu/RHEL. Why would you even need to backport fixes if you have a CI system that builds from source? The only systems doing massive CI are distros like Arch/Alpine/Void/etc because there package manager is designed with it in mind. Apt is better than RPM, but it still has shortfalls when it comes to creating and maintaining packages.

> Containers are great for scaling, and terrible for software distribution. Done right, they need to be rebuilt daily to pick up the latest fixes in the underlying OS.

That isn't called building right. If your package has that many dependencies, then you could just bind mount the tool. No need to rebuild the container at all, however most of the time you don't need to rebuild that often, especially for Go.

> Snap and AppImage mean you're on the hook for care and feeding of every library you bring in, yourself.

They have a simple YAML setting that does this for you

> Rolling distros mean that you need a staff to integrate all the changes that are happening with no cadence other than "apparently today's update broke X". More likely, it would be a team dedicated to "apparently Y has been broken for a week, we found the problem, we're trying to upstream it, but now service X relies on the new functionality, so we're doing a conference call with them tomorrow to find out if they can roll back that change."

Rolling distros doesn't require that you upgrade a package, and I've never had a problem rolling back using my cached repo or one of the mirrors that caches packages daily.

Whoosh.

Package managers and containers are fairly different things. For internal distribution of software, for example, apt can be better (less disk usage, less configuration issues, better integration with other programs...). Recommending one or the other in such a broad way is just misguided and will cause problems.

I also find myself reaching for apt/yum/dnf/apk for standard tools when creating a container rather than building everything from scratch. It seems odd to me to waste time doing what someone else does well already.

If you trying building a package for Arch/Alpine you'll understand why I recommend it over APT/RPM. Also, caching is much easier with Arch/Alpine.

How do you dependency management inside the container?

There are multiple ways. I think the general solution is to compile statically, however for libraries you can bind mount what you need. I don't think Docker provides a complete solution, but I pretty much prefer anything over RPM/DEB packages.

Reply on news.ycombinator.com