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

[Anders F Björklund]

Ryan Schmidt wrote:

>>> 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.

At least not yet. When installing from packages, it's a feature
that you don't have to install all the build requirements too.
It's not so much the _size_ of the headers and library symlink,
although all those static libraries currently used do add up...

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

Right, although it's somewhat strange to have versioning information
in the name (as a concept). Maybe makes more sense in a "testing/" ?
At any rate, there's a lot of workarounds with files and whatnot -
due to the fact that they don't live in the same namespace now...


>> [...]
>> 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.

No system copy... yet. When there is, like it was added in FreeBSD,
it will be automatically picked up. Just the variable was missing.

It didn't work fine, as you couldn't upgrade the "xz" port when
using .txz archives since base was depending on the port itself.
If it had been using a (theoretical) "gzip" port, it would have
had a similar problem for .tgz archives (packages, not distfiles).

Anyway, I'm sure the change doesn't help anyone but me... But it
was still using lzma_path and xz_path, just no place to set them ?

	if {[info exists portutil::autoconf::${gzip}_path]} {
		set hint [set portutil::autoconf::${gzip}_path]

--anders