Setting up

Feedback

Pretty webpage describing packages

Donation

Out of scope

Waffle/Motivation (don't read this bit. what are you, bored?)

1. Are you old enough to remember getdeb and playdeb?
2. Canonical moves all kinds of stuff to snaps. I hate snaps and snapd. Haiku does it better. FreeBSD does it better.
3. Universal packages (yes, like snaps) are EASY for third parties, which is making debs harder to find (eg OpenRA, Zero-K)
   • OpenRA saves aren't acknowledged by the snap, and the author provides no clear migration path
   • Zero-K is normally distributed through Steam now - or itch.io - great systems, but not for everyone
4. Lots of things can't be packaged by/for Debian because of licensing or quality/manpower issues
5. There is so much great stuff out there that nobody has ever even compiled for Linux, or is affected by the previous point - we're missing out on it
6. Um, sometimes I might write something I guess
7. OK so there are companies out there who have deb packages but then don't include them in repositories. DISCORD! I don't want to have to open my browser, go to a website, download some file, and then open that file and run the install thing, then go back to what I was trying to do a moment ago. Gosh heck, make it automatic! How can you put it in debs and not write an index for a repo?!
8. Possibly in future I may want to consolidate packages from several sources, as Pop! OS and Mint do (eg Mint has Spotify debs, I think, which normally you get from another repo)
9. This gives me a bit of hands-on experience with CI, packaging, fiddling with random projects, finding and evaluating software, rewriting build scripts etc
10. Remember that point about getdeb? I wanna do some good, you know?
11. ... There is an ever-expanding plethora of packaging techniques out there. Some simple, some complex. Some good, some bad. Some popular and some infamous or obscure. Old, new, everything in between. The wheel gets invented and reinvented and reinvented. It could be an unnecessary duplication of prior efforts, and it could be real progress. There sure are a lot of ways to make even just Debian packages, and the universe continues to evolve there.
    • Debian source format 1, 2, 3, and quilt, native, git and whatever else
    • Microsoft's own Winget
    • Chocolatey, Homebrew
    • Snaps, Appimages, Flatpaks
    • Portage
    • The AUR
    • Haikuports
    • RPMBuild
    • dpkg-buildpackage, debuild, pbuilder, cowbuilder, cowbuilder-rpm, mock...
    • fpm, a universal packager
    • specs for the OpenSuse buildsystem, whatever that's called
    • npm, composer, pip, pecl, pear, maven, nuget, all the intricate github/gitlab workflows...
    Now hey, what's best? I don't know. I think it'd pay to understand the GIST of how debian and haiku and arch and red hat like to do it. Maybe not that set, but... You get the idea. What do I think so far? The binary format for debs is bloody superb. Quilt takes a bit of getting used to. AUR and Haikuports both have build recipes which run like shell scripts, and look much easier to assemble. They lose some rigidity I guess - Lintian is really brutal :-). But I think this is why people invent fpm and other metapackaging projects. Most third-party binary/source debian archives deviate wildly from debian standards (my own packages included). It can be pretty tricky getting something perfect. One of my main problems with the debian format is how hard it is to store the information. The most-used tools have strict requirements about repository structure or location of metadata, and those requirements are not always practical to meet or easy to learn. One day, maybe, we can have a neat recipe like in AUR or Haikuports, that assembles the source package from a remote repository and a local directory. We seem to be heading in that direction with the likes of format 3.0 (git) and git-buildpackage. But it isn't quite sitting right with me yet. This is an area that I'd eventually like to play around in. Bear in mind I don't want to reinvent the wheel or create YET ANOTHER way of doing things. I'm trying to not do NIH too hard.
12. I'd like to have a sane and traditional way set up to build packages for a few different platforms. Obviously RPMs are on the roadmap. I'd also like to write recipes for AUR and Haikuporter, AND, generally (at least for my own software) I'd really like it if I could automatically package for Windows also. Granted, that's probably the hard bit - I'm not sure. I am throwing heaps of time and imaginary money at implementing it all directly in buildbot.
13. When the packages are production quality, I'd like to push them through to a PPA and any other semi-official, reliable thing I can. Open Build Service, too, I guess. Whatever, Most packages are still a bit rough around the edges...