Hacker News new | past | comments | ask | show | jobs | submit login

> monstrously complicated packaging apparatus

Huh?

.debs are gzip'd tar file with predictable top-level folders and some manifest files. An APT server can be as simple as an FTP site, again with a predictable hierarchy and some manifest files.

Keysigning gets a bit messy but it is still relatively simple.

You can set up your own private package repository in minutes using nothing more than ftpd, gpg, mkdir, and vim.

The documentation is clear, comprehensive, and relatively easy to read.

How is this "monstrously complicated"?




Try to build deb package according to packaging guidelines.

If you are new to debian packaging, make a reservation in your calendar for several evenings, just to figure out what exactly you have to read through.


Did that. Ran an internal APT server for years. Was a fantastic system for doing remote installs on field installations.

Like, you create a folder structure that mimics the final installation inside one of the two toplevel deb folders. The other folder had a manifest or two. Worked easy, and did not take long to figure out

https://blog.knoldus.com/create-a-debian-package-using-dpkg-...


Creating a deb is really easy

I have a script which does various things with git to get a copy of the latest code, tag it, then runs something like

fakeroot dpkg-deb --build ./$packageName/src $packageName.deb

In that src file are things like "usr/whatver", "opt/whatever", "etc/whatever" and "DEBIAN"

In DEBIAN is a really simply control file and sometimes some scripts to do things on install.

Getting a package approved by the debian maintainers is an issue if you don't follow the guidelines (and lintian will help) - just like getting a package approved by the redhat maintainers, but to make your own deb is barely harder than creating a tarball.


> Creating a deb is really easy

That's why I qualified it "according to packaging guidelines".

And I don't want to comply with packaging guidelines because I want to get it into the upstream repo; no, I want it compliant so it is not broken at upgrade time and I don't want to have to solve several problems at once at the most inconvenient time.

With rpm it is both easy and piecemeal - you don't have to have the entire knowledge in your head upright, you can improve it continuosly. You start with spec file and rpmbuild, then find out about rpmlint, then you will find out about mock (so you can build package for Fedora-any version and CentOS-anyversion from any distribution, including Ubuntu or Debian, inside chroot or container) to koji (full blown distro-scale build system).




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: