[80313] trunk/dports/devel/liblzma/Portfile

[Ryan Schmidt]

On Jul 27, 2011, at 03:27, Anders F Björklund wrote:

> Ryan Schmidt wrote:
> 
>>> The waste in this case is much more than using the .gz format or using two subdirs. There is no reason why the xz port should be statically linked, and the headers/libraries in a separate port - except for the poor upgrade and library handling by MacPorts (in general). It would make more sense to roll the "liblzma" port into the "xz", but even that won't work as long as base is using xz from port rather than from the system (i.e. upgrading xz itself).
>> 
>> I don't understand what's preventing us from consolidating the two ports into one, if that's desired.
> 
> Maybe adding a "replaced_by xz" to the liblzma port would do the trick, haven't tested if it works. I'm a bit torn, on the one hand I do like properly separating them but on the other hand it shouldn't different from all other ports...

Right, I can't think of any other ports in MacPorts that separate this way, so probably this shouldn't be.


>>> But at least that way it would behave like every other port, until the subpackage feature is available ?
>> 
>> My understanding is that subpackages are available now in MacPorts 2.0.0, if that will help things.
> 
> As far as I know, the subport feature would allow you to declare several ports in one Portfile. But each port would still have both deployment and development files in the same package, so no split like *-dev .deb or *-devel .rpm ?

...right, we don't do that kind of thing in MacPorts. Other package managers might have that separation; we don't.

And we have a different use for the "-devel" naming convention already (see #14540).


>>> And I'll add lzma and xz detection to configure, next to the gzip and bzip2...
>> 
>> How do you mean?
>> 
> 
> ... to the configure of base, that was (not the configure of xz).
> See http://trac.macports.org/changeset/81171 (lzma_path + xz_path)
> 
> Now it will use my /usr/local/bin/xz, rather than shooting itself
> in the foot when trying to upgrade "xz" while using .txz archives.
> 
> If you prefer to have base use ports for lzma/xz, that will still
> be the default if there's no lzma/xz found at base's configure-time:
> 
> checking for gzip... /usr/bin/gzip
> checking for bzip2... /usr/bin/bzip2
> checking for lzma... no
> checking for xz... no
> 
> But if you want a standalone xz, you can use /usr/local or /opt/xz ?
> Unfortunately it's still not provided by system, but available here:
> 
> http://afb.users.sourceforge.net/xz/
> 
> Using /opt/xz might be better than /usr/local, unless you are prepared
> to deal with things picking up headers and libraries (for liblzma) too.

I guess then I don't understand the purpose of the change. It worked fine as it was. And as you say there is no system copy of lzma or xz, and we don't support users using other standalone software, for example in /usr/local. And thus the xz port cannot use an xz distfile. Seems logical to me and not an error that needs to be fixed.