Nice! Seems like someone created a Debian package a few years ago an abandoned it. May be a good starting point for creating a new package that would also build freenet
You are so skeptical about everything :)
Yes, but not because I am evil, because breakage easily happens. ;)
For qubes-9.x for example we now have the “stable rather than wheezy” upgrade issue as well as the “/etc/hosts immutable” issue. Once users run into these, those are difficult to resolve. Those can most times be resolved, aka “edit this postinst script, add ‘exit 0’ below ‘#!/bin/bash’” or such instructions, but that’s cumbersome for users to do and for us to support.
Maybe we have different assumptions, goals. My goal is to maintain a super simple linux distribution that is easily upgradeable, ideally without need for special commands other than the usual upgrade commands. Any package manger issues generates lots of, partly concerned, support requests. The more users, the more support requests.
We could very well end up in a situation where we need to say “no, you cannot [easily] upgrade qubes-whonix 9 to qubes-whonix-10 [unsupported]”. This is not the end of days, but bad. Then users wonder why that is and how to migrate and run into migration issues and so forth. And other users who stick with old versions and then create invalid bug reports. Otherwise we need to maintain special instructions for upgrading and then helping lots of users with special cases. Or just write the instructions and then give a damn about it. Let users figure out themselves and ignore the questions. All non-ideal.
I think non-clean solutions, packaging issues lead to a lot bugs that generate a lot extra work. Therefore it’s my strategy to try getting up real solutions [upstream] rather than distribution specific hacks and workarounds. Because those hacks and workarounds pile up. I fear they pile up to a state where complexity gets unmanageable. Each special case needs explanation, gets questioned every now and then, is prone to interaction bugs with other packages and still needs to be understood in two years from now. Therefore it’s my strategy to use existing tools rather than reinventions if sane, using standard tools, policy conform, lintian clean packages, again with the goal of having very few bugs, simplicity and no package manager upgrade issues.
For the most part when dealing with packages and repos, etc salt uses the functionality of the distribution it is installed on. Therefore it would be considered standard compared to non-standard I would think.
Doesn't sounds too bad.
and would also depend on the PITA factor of maintaining the Debian package for freenet.
I think it may be worthwhile to find out why it was abandoned in the first place.
By the way, there is this team that might be interested:
Once you created a Debian policy conform, lintian clean Debian package, they might takeover the regular maintenance upgrades.