[124087] trunk/dports/sysutils

[Anders F Björklund]

Ryan Schmidt wrote:

>>>> rpm5x: replace with 5.4.x
>>> 
>>> This is not sufficient to replace a port. For the proper procedure, see https://trac.macports.org/wiki/PortfileRecipes#replaced-by
>> 
>> Well, it would be OK for any users of the old ports to keep using them.
>> Instead of adding these empty pseudoports with a fake pre-configure ?
>> 
>> Just wanted to avoid new installations of the legacy versions, but OK.
> 
> That would accomplish that, yes, but I don't understand why that's the user experience you wanted to provide. Either there is value for some users in having these old ports installed, in which case the ports should remain intact and installable, or there is no value in having these old ports installed and users should be guided toward upgrading to newer versions, which is what the replaced_by recipe does.
> 
>> I'll revert the commit, so you can make a real decision about RPM...

If you really want to help your users upgrading from RPM 5.x to the latest,
then it needs to talk them through upgrading the rpmdb and other changes ?
Whether it is converting from SQLite to Berkeley-DB, or going from 5 to 6.
I'm not sure the recipe handled that, or if there even are upgrade scripts.

Still not sure what it is trying to accomplish, or which version is the
preferred one now that there are no longer any links from MacPorts base.
So that is the more interesting decision, what you actually want to keep
in the distribution and what should be removed. It seems rather arbitrary ?


So you get tickets like https://trac.macports.org/ticket/36318 and
https://trac.macports.org/ticket/38456 asking for even more complexity
with "select" ports and all the versioned rpm dependencies and what not.
Maybe just delete them all, and ask users to use something other than port ?

Or decide where it is heading, is it providing upgradeability from DarwinPorts
or it is providing compatibility with Linux and Fedora or what is the purpose.
The original user experience, of providing a package manager where there was
none (or none that met the requirements, looking at you pkg/bom) is now gone.


Either way, the ports go back to the status quo until the goal is known...

Currently that is 5.2.1, with a possible upgrade to 5.4 - like in Homebrew.


>> PS. The example is wrong. xz-devel (4.999) was "upgraded" to xz (5.0)
>>   and then xz-devel went onwards to 5.1alpha versions instead...
> 
> The example was accurate when written. :) xz-devel was replaced by xz in December 2010. I added the replaced_by recipe including the xz-devel/xz example in April 2011. xz-devel was revived in August 2011. It is in the nature of documentation to become outdated, but it can certainly be updated or changed to a different example.
> 
> 
>>   That is the very nature of the -devel ports, since you don't have
>>   any "testing" area.
> 
> Right.

So more like a bug in the implementation, than something to document...
If there was staging areas, one could have a single "xz" port throughout.

But that's not how MacPorts wants to work. The other -devel ports were
removed because they built HEAD/trunk, and that is not supported either.
i.e. the ports are "supposed" to build a defined version, which means
that you can't have them as build recipes for the latest and greatest ?

Which is getting increasingly hard, with fewer real releases and more of
rolling releases happening ("just get the latest from our github account").

Anyway, that is why my own devel ports were removed.

But I suppose you can still use the idea for stuff that are stuck in a
perpetual beta, like the "xar-devel" port (1.5.3? 1.6?) for instance.

The others are just left locally and not committed.

--anders