[94838] trunk/dports

[Anders F Björklund]

Ryan Schmidt wrote:

>>> I thought it was nice having them split up, especially if liblzma is licensed differently from the xz command line utilities.
>> 
>> I thought so too, but that's not how things are done in MacPorts.
> 
> If there are license-related reasons why doing so would be beneficial, then absolutely we should be doing so in MacPorts. It's fairly common for a package to include both command-line utilities under the GPL and libraries under the LGPL. It would be best to have those in separate ports (or probably better yet subports) so that ports that depend on the library don't get unnecessarily constrained by the GPL.

The library now gets unnecessarily constrained by the GPL...

Is it common to use subports for this ? I haven't seen any
other software that splits ports into program and library.

> As another example, the pianobar port has a libpiano subport. In this case, it's not a license issue, merely the situation that they're two separate pieces of software, which don't require one another, which the user might install for separate reasons.

Neither bzip2 nor gettext splits into separate installs,
so I thought there was no reason for xz to do so either...

It was also very inconsistent about linking (static/shared)

>> Actually I think the best would be to have liblzma included with
>> the system like it is in FreeBSD, but that's not happening and
>> MacPorts wouldn't use it anyway like it ignores zlib and bzip2.
>> So it's being made available in /usr/local, rather than /usr...
>> 
>> Feel free to hack the configure phase etc of liblzma, bumped rev.
> 
> I've fixed liblzma now in r94975. In the future please make sure to follow the recipe or the guide or use the "obsolete" portgroup when replacing ports, so that users don't run into the problems they ran into this time.

But above you're saying that you want the liblzma port back again,
which wouldn't rhyme with your "fix" plus that it now looks weird ?

Instead of something automated, there's now a failing configure
stage and an error message for the user. Not really an improvement.
It also needs to carry that stub liblzma port around, just because
the "replaced_by" is placed on the wrong side (and not "replaces").

But if you want to do it like that, then please take over the port...
I guess it has to be lived with for a year to come, unless reverted ?

>> If port can't handle replaced dependencies, I guess they would need
>> to be replaced manually (i.e. swapping "liblzma" depends for "xz")
> 
> Yes, that is also part of what you need to do when you replace a port.

I thought it would be fulfilled by the old xz 5.0.3 and liblzma 5.0.3
pair, until you decided to upgrade your xz to 5.0.4 ? But maybe not.

--anders