Making Packager-Friendly Software (O'Reilly)
A package maintainer, or packager, is a person who creates packages for software projects. He eventually finds common problems in these projects, resulting in a complex packaging process and a final package that is a nightmare to maintain. These little flaws exist because in most cases the original developers are not packagers, so they are not aware of them. In other words, if you do not know something is wrong, you cannot fix it. This article describes some of these common problems and possible solutions."
Posted Apr 7, 2005 5:38 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (4 responses)
On the contrary; these days a vast number of programs build simply enough with configure, make, make install, and just "configure --prefix=/some/place" if you want it somewhere else. Yes, it's an issue if the configure script makes decisions based on the presence or absence of some prerequisite, but that's the packagers' problem. Hey, he's a BSD guy; he can build a nice controlled chroot jail to make sure his package works, and he can provide all options explicitly.
The idea that people who aren't developers can build themselves from source is too good to give up just to make life better for a much smaller population.
Packager friendliness is a good idea, but not if it forces everyone to provide extra options to configure.
Posted Apr 7, 2005 14:06 UTC (Thu)
by NAR (subscriber, #1313)
[Link]
Usually it's not the building process itself that is problematic - did you try to get the 40-odd development libraries needed to compile e.g. mplayer with full functionality? That's where an 'apt-get build-dep' mechanism could be really useful.
Posted Apr 7, 2005 22:48 UTC (Thu)
by kmccarty (subscriber, #12085)
[Link] (1 responses)
I take issue with one of this guy's arguments: he wants to make life easier for packagers at the expense of people who "build by hand", and says that people who "build by hand" should "pay the consequences", as if it is a wizardly or risky thing to do. Speaking as someone who maintains a few Debian packages, I agree with you. The people who should have the skills to be "wizardly" are the packagers, not the end user who just wants to compile something that doesn't yet exist in his/her distribution. That said, the rest of his article is well-stated, and there is an awful lot of open source software that is a nightmare to build both for packagers and for end users. I wrote a similar
thing myself at one point out of frustration:
Physics Software Rant
Posted Apr 9, 2005 1:06 UTC (Sat)
by dberkholz (guest, #23346)
[Link]
Posted Apr 13, 2005 15:56 UTC (Wed)
by jschrod (subscriber, #1646)
[Link]
Joachim
Posted Apr 7, 2005 13:02 UTC (Thu)
by horen (guest, #2514)
[Link] (1 responses)
When I install a system -- either a desktop workstation or a server -- I install only the minimum set of RPMs necessary for the host to successfully arrive at bootlevel 3 (or 5). That's it for packaged software.
Afterward, I install everything else -- all "extras" -- from source, compiling/configuring for /usr/local operation (on a server, I place BIND, Sendmail, and a few others in the same locations as their RPM counterparts). Thankfully, some packaged-binaries conform to this model, such as Firefox and Thunderbird.
In a networked environment, all "extras" are installed on file-servers and /usr/local is made available for automounting.
In a standalone environment, I believe that it is no less important for "extras" to be placed in /usr/local (i.e., installed/compiled/configured from source), in order to prevent them from being overwritten by system upgrades or automatic updates. Even better is to place /usr/local on its own partition or disk.
I have used this model in both academic and commercial settings, and it has never failed me. YMMV.
Posted Apr 7, 2005 14:00 UTC (Thu)
by NAR (subscriber, #1313)
[Link]
So you do fetch the source/patch, compile, install, optionally remove not used files and update configuration files every time there is a new version/fix for a security bug instead of waiting for the distributor to package the new/fixed software and install it with an "apt-get-like" mechanism, don't you? Well, it might be faster and more secure, but I wouldn't want to do it as a desktop user...
I take issue with one of this guy's arguments: he wants to make life easier for packagers at the expense of people who "build by hand", and says that people who "build by hand" should "pay the consequences", as if it is a wizardly or risky thing to do.
Making Packager-Friendly Software (O'Reilly)
a vast number of programs build simply enough with configure, make, make install, and just "configure --prefix=/some/place" if you want it somewhere else.
Making Packager-Friendly Software (O'Reilly)
Making Packager-Friendly Software (O'Reilly)
Much chemistry and biophysics software is in the same rut. =\Making Packager-Friendly Software (O'Reilly)
But actually his --enable-packager-mode is a good proposal that addresses the issue and gives everybody the choice he wants. It must not be the default, but it is a Good Thing(tm) for those downstream who want to have more control. At least for my software, I'll include it in the future.Making Packager-Friendly Software (O'Reilly)
Since becomming a sysadmin in 1988 (SunOS/3.2), I've learned to differentiate between system and "extras" files, and use different types and methods for installing them.Making Packager-Friendly Software (O'Reilly)
I have used this model in both academic and commercial settings, and it has never failed me. YMMV.
Making Packager-Friendly Software (O'Reilly)