Quoting Steve Litt ([email protected]): > I don't know how to do the preceding, and I'm forever prioritizing > other things above learning it.
Well, if you have a spare hour some time, try debhelper[1] or CheckInstall[2]. You might be surprised. (Above and below, for the sake of present discussion, I'll assume we're talking about a deb-based distribution. For other package toolkits and other package-oriented distributions, there are similar toolsets.) > I recognize what you say, freely admit that your viewpoint is a > majority viewpoint for informed Linux users. But at a gut level, I've > never been able to believe it. Common ground first: In general, the stuff you put together is (blessedly) self-contained, mostly, the very opposite of a dependency hairball. So, the likelihood of eventual breakage because your tarball-compiled software is unaware of the tracked packages and the package-tracking software is unaware of your tarball-compiled software is really small. (This is like my footnote's example of locally compiled leafnode.) My concern is mostly that you're giving _generally_ bad advice that is likely to bite people if/when they keep applying it, and apply it to software more interdependent with the rest of the system. If you merely said 'Hey, I do this because it's convenient in this case, but you could get in trouble if you ignore package management on a package-oriented distro in a carefree way as if it didn't matter', I'd be fine with that. But instead, your writings (in particular cases) go out of your way to _specifically discourage_ people from bothering to use package management. Worse, your essays portray the Linux admin's choice as a dichotomy between badly designed distro packages on the one hand and appropriately tailored locally compiled tarballs on the other -- as if it were impossible to use backports.org packages, unofficial repo packages, or locally built packages the admin constructs based on tarball compilation. E.g., using debhelper or CheckInstall. I think your advice is quite bad for readers, in that regard. I think people are going to get in trouble followiing it. And I think this ought to trouble you. > Sure, 99% of my software is package-installed and I like it that way, > but for certain software that's very important to me, if I don't like > the way the package does it, it's off to ./configure;make;make > install. I regularly do this for LyX, Bluefish, Sigil, and all the > process supervisors. I have absolutely no problem with that. (Again, like me with leafnode.) But then, it's really odd that you don't do the extra 10% work to make a local .deb out of that. At which point, by the way, you could then also help others by offering it to the public. And, if you had bothered to read what I said upthread, and in my footnote, that's what I've been saying. Or, you _might_ be able to save yourself even the trouble of compiling locally (and then having to keep on top of updates and maintenance forever after that) if you find that someone else with an unofficial .deb repo is doing the work so you don't have to. IMO, you keep doing your readers a disservice by never mentioning these things. (My opinion, yours for a small fee. And if I didn't respect and value you as a writer, I wouldn't bother to say this.) [1] https://faceted.wordpress.com/2011/05/18/howto-build-a-trivial-debian-package-with-dh_make/ [2] http://checkinstall.izto.org/ _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
