libtool vs. libtool-devel
I was seduced by the libtool-devel port (v. 1.9f), which caused me to deactivate the libtool port (v 1.5.24) in favor of it. As it turns out, the automake folks told me 1.9f is pretty old. The other kicker which got me to try libtool-devel was that the libtool port doesn't actually install tools named "libtool" and "libtoolize". I was looking for libtoolize, so assumed without investigating that if 1.9 > 1.5 and 1.5 doesn't have libtoolize, maybe 1.9 would have it. Given the naive view that a larger version number implies something a bit more current and "-devel" implies something a bit more development-oriented, shouldn't the libtool-devel port either be renamed or deleted altogether? -- Skip Montanaro - skip@pobox.com - http://www.webfast.com/~skip/
On Jan 7, 2008, at 18:51, skip@pobox.com wrote:
I was seduced by the libtool-devel port (v. 1.9f), which caused me to deactivate the libtool port (v 1.5.24) in favor of it. As it turns out, the automake folks told me 1.9f is pretty old.
libtool-devel is unmaintained so it wouldn't surprise me if it's out of date. As all unmaintained ports, it's open for adoption.
The other kicker which got me to try libtool-devel was that the libtool port doesn't actually install tools named "libtool" and "libtoolize". I was looking for libtoolize, so assumed without investigating that if 1.9 > 1.5 and 1.5 doesn't have libtoolize, maybe 1.9 would have it.
According to "port contents libtool", it installs glibtool and glibtoolize, not libtool and libtoolize, because that would conflict with Apple's libtool, which is not the same as GNU libtool and should therefore not be replaced with GNU libtool. libtool-devel also uses the "g" prefix.
Given the naive view that a larger version number implies something a bit more current and "-devel" implies something a bit more development- oriented, shouldn't the libtool-devel port either be renamed or deleted altogether?
The "-devel" suffix indicates a development (non-production-quality, pre-release) version of a port, according to the definition of the developer of the software. To what would you suggest the port name be changed? I think the name "libtool-devel" is accurate, since the port does install a development version of libtool. It can be deleted, but presumably the better course of action would be to update it to the latest development version of libtool. Although, according to http://www.gnu.org/software/libtool/, 1.9f is the latest development version, though it is over 3 years old. I guess the 2.1a version is newer, but they seem to be releasing daily new versions of 2.1a, which isn't helpful.
>> Given the naive view that a larger version number implies something a >> bit more current and "-devel" implies something a bit more >> development- oriented, shouldn't the libtool-devel port either be >> renamed or deleted altogether? Ryan> The "-devel" suffix indicates a development Ryan> (non-production-quality, pre-release) version of a port, according Ryan> to the definition of the developer of the software. Sorry, I'm used to common convention in the Linux arena where the XXX-devel package contains the .h files and such necessary to compile code that uses XXX, while XXX is a binary containing the libXXX library (.so files, etc). Ryan> To what would you suggest the port name be changed? I think the Ryan> name "libtool-devel" is accurate, since the port does install a Ryan> development version of libtool. Ryan> It can be deleted, but presumably the better course of action Ryan> would be to update it to the latest development version of Ryan> libtool. Although, according to Ryan> http://www.gnu.org/software/libtool/, 1.9f is the latest Ryan> development version, though it is over 3 years old. I guess the Ryan> 2.1a version is newer, but they seem to be releasing daily new Ryan> versions of 2.1a, which isn't helpful. Given that it's unmaintained, I can't see that deleting it should be all that big a deal. It's apparently way behind the current development bleeding edge (which as you suggest might leave one pretty bloody to use it). I guess that given the meaning of "-devel" (is that a consistent meaning throughout MacPorts?), it's best left as-is. Once burned, twice shy, so I will stay away from -devel packages in the future unless there is no alternative. Thanks, Skip
On Jan 7, 2008, at 21:58, skip@pobox.com wrote:
Given the naive view that a larger version number implies something a bit more current and "-devel" implies something a bit more development- oriented, shouldn't the libtool-devel port either be renamed or deleted altogether?
The "-devel" suffix indicates a development
(non-production-quality, pre-release) version of a port, according
to the definition of the developer of the software.
Sorry, I'm used to common convention in the Linux arena where the XXX-devel package contains the .h files and such necessary to compile code that uses XXX, while XXX is a binary containing the libXXX library (.so files, etc).
Right, that's a difference between MacPorts and some other package managers. In MacPorts, the .h files and other necessary files for compiling code are already included in every port. The -devel ports are merely newer development versions of the software (or, sometimes, older versions of the software, in the event that no new development versions have been released following a stable release).
It can be deleted, but presumably the better course of action
would be to update it to the latest development version of
libtool. Although, according to
http://www.gnu.org/software/libtool/, 1.9f is the latest
development version, though it is over 3 years old. I guess the
2.1a version is newer, but they seem to be releasing daily new
versions of 2.1a, which isn't helpful.
Given that it's unmaintained, I can't see that deleting it should be all that big a deal. It's apparently way behind the current development bleeding edge (which as you suggest might leave one pretty bloody to use it). I guess that given the meaning of "-devel" (is that a consistent meaning throughout MacPorts?), it's best left as-is.
Ok, let's leave it for now. Perhaps the libtool developers should be encouraged to release a new development version. Surely something useful has been changed in the past 3 years to merit a new release.
Once burned, twice shy, so I will stay away from -devel packages in the future unless there is no alternative.
Right, there's usually no need to install -devel ports. I don't have any installed.
participants (2)
-
Ryan Schmidt
-
skip＠pobox.com