On Thu, 31 Dec 2015 13:05:46 -0500
Miles Fidelman <mfidel...@meetinghouse.net> wrote:
> I'm really not sure where to bring this up, but this seems like as
> good a place as any, as it's been looking for alternatives to Debian
> that has flagged this issue for me (other suggestions welcome).
>
>
> In looking at Devuan, and a few other non-systemd distros (Gentoo,
> FreeBSD, GUIXSD in particular), I've noticed that documentation of
> how to install and manage unpackaged software seems to have almost
> disappeared. An awful lot of distros now seem to assume that
> EVERYTHING is packaged.
>
> Of course, the reverse is far more common - at least that's been my
> experience.
>
> - developers tend to distribute source, built in their
> language-specific development environment, "packaged" for
> cross-platform building (e.g., a .tar file created using gnu
> autotools), or a .jar file, or what have you -- (well constructed)
> source generally compiles, installs, and runs cleanly
> [parenthetically, assuming an init system that recognizes sysvinit
> files!]
>
> - it's pretty rare for developers to package for more than a few,
> particularly popular distros (if they package at all).
>
> - when building production servers, it's a lot more reliable to
> "./config; make; make install" than to rely on packages (yes, for a
> lot of the platform stuff, packages save time, but as one goes up the
> stack, current packages are less common)
>
> - an awful lot of stuff uses its own dependency resolution mechanisms
> and repositories (e.g., perl w/ cpan)
>
> Somehow, I think this is something we need to be concerned about for
> Devuan; but that also seems of concern to the broader Linux (and
> Unix?) ecosystem.
>
> Comments, thoughts?
Hi Miles,
I guess I'm an "upstream", being the originator of the VimOutliner
project (probably a few thousand users), the UMENU project (probably
about 10 users), the Amounter project (2 confirmed users), and several
less-used pieces of software.
As a Developer, I'm not a fan of packaging, because from the very
outset I try very hard to make my software have minimal dependencies,
I try to make its dependencies universally available, and if it's C I
make it cc -Wall myprogram with no errors or warnings. Except for the
notoriously undeployable UMENU, my stuff goes on with a few copy
commands and maybe a compile. No need to obfuscate it with a package.
At the VimOutliner project, when people came to us with hopeless
foobarred VimOutliner installations, then we asked them how they
installed, invariably it was with their distro's package. Rather than
debug the hopelessly exglomerated package results, we had them
uninstall and reinstall with the tarball right off our website,
following our instructions. This always either fixed the problem, or
created a situation where it was easy for us to debug.
As a user, of course I'm not going to hand compile LibreOffice, Sigil
or Firefox (Iceweasel). My mama didn't raise no fool.
But when it comes to all of djb's stuff, alternate init systems,
project supervision software, or newer than newest versions of LyX,
I ./configure;make;make test;make install. Again, my mama didn't raise
no fool. I know that if I install djbdns (requiring daemontools and
some sort of tcp plugin), I'm in for 2 to 3 hours of very carefully
following a recipe, looking up a couple workarounds, and then maybe an
hour of debugging. When installing djbdns from Debian packages (I tried
this a couple times), I know I'm in for 6 hours of "what the heck is
this stuff, and where can I find documentation specific to this setup?"
Packages and package managers are a great thing. I'd never want to
forego a good package manager. You'll never catch me hand-compiling
Firefox. But in my opinion, sometimes you're much better off kissing the
package manager goodbye for a specific app, and
using ./configure;make;make test;make install, or whatever else the
README or INSTALL file tells you to do.
SteveT
Steve Litt
November 2015 featured book: Troubleshooting Techniques
of the Successful Technologist
http://www.troubleshooters.com/techniques
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
