
Show HN: OpenAPT first release – Automate your APT repositories layouts - rmedaer
https://github.com/ALLOcloud/OpenAPT
======
djsumdog
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...](https://github.com/BigSense/vSense/blob/master/ansible/roles/repo/tasks/apt.yml)

[https://github.com/BigSense/vSense/blob/master/ansible/roles...](https://github.com/BigSense/vSense/blob/master/ansible/roles/repo/templates/aptly.conf.j2)

Publishing was kinda a nightmare:

[https://github.com/BigSense/vSense/blob/master/ansible/roles...](https://github.com/BigSense/vSense/blob/master/ansible/roles/build/templates/ltsense.jenkins.xml.j2#L53)

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!

~~~
rmedaer
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.

------
cassianoleal
Nice!

A few years ago a coworker wrote a similar thing
([https://github.com/queeno/aptlify](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!

------
kitotik
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?

~~~
rmedaer
What do you mean by "closed apt" ?

~~~
kitotik
Exactly.

What is meant by “OpenAPT?”?

~~~
rmedaer
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!

------
techntoke
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.

~~~
alrs
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."

~~~
techntoke
> 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.

~~~
alrs
Whoosh.

