docbook-utils @ 0.6.14 Update perl requirement to 5.22

[lockhart (Thomas Lockhart)]

docbook-utils previously required perl-5.16. Update to using perl-5.22 per current MacPorts recommendation.

See also #50220.

[lockhart (Thomas Lockhart)]

Update to perl-5.22. Parameterize the perl version number.

[mojca (Mojca Miklavec)]

See also #50220 that needs to be addressed first.

[mojca (Mojca Miklavec)]

There are some further problems:

SGML_CATALOG_FILES=/opt/local/etc/sgml/catalog \
	SGML_SEARCH_PATH=../../doc:.. \
		onsgmls ../../doc/docbook-utils.sgml | \
		sgmlspl-5.22 ../../helpers/docbook2man-spec.pl
onsgmls:/opt/local/etc/sgml/catalog:2:8:E: cannot open "/opt/local/share/xml/docbook/4.2/docbook.cat" (No such file or directory)
onsgmls:/opt/local/etc/sgml/catalog:4:8:E: cannot open "/opt/local/share/xml/docbook/4.1.2/docbook.cat" (No such file or directory)
onsgmls:/opt/local/etc/sgml/catalog:6:8:E: cannot open "/opt/local/share/xml/docbook/4.3/docbook.cat" (No such file or directory)

Shouldn't the port build_depend on opensp that provides /opt/local/bin/onsgmls? And on docbook-xml-4.2 and other versions? Or where do all these dependencies come from?

There are also some problems like

		sgmlspl-5.22 ../../helpers/docbook2man-spec.pl
onsgmls:/opt/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:8:19:E: "X21B6" is not a function name
onsgmls:/opt/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:8:19:E: "X21B6" is not a function name
onsgmls:/opt/local/share/xml/docbook/4.1.2/ent/iso-amsa.ent:9:19:E: "X21B7" is not a function name

[mojca (Mojca Miklavec)]

I committed r144343 with the changes because that was really the last port that needed the upgrade to 5.22. But we need to figure out what's with all those failures that I'm experiencing.

[lockhart (Thomas Lockhart)]

Replying to mojca@…:

I committed r144343 with the changes because that was really the last port that needed the upgrade to 5.22. But we need to figure out what's with all those failures that I'm experiencing.

You have entries in /opt/local/etc/sgml/catalog which point at files which do not exist on your system. I have the same entries, but have the files in question (e.g. /opt/local/share/xml/docbook/4.2/docbook.cat).

The problem with "is not a function name" is due to a missing secondary XML or SGML catalog.

Several SGML and XML ports reference these catalogs, and formerly they had a bunch of duplicate (or nearly duplicate - ugh) code which tried to manage these catalogs. A while ago I modified these to use the "xmlcatalog" portgroup to consolidate this duplicate code. I would expect that these catalogs get consistently augmented and diminished when ports are installed or removed, but extra duplicates are not detected and are not removed. I'm guessing that you have an inconsistent set of catalogs dating from before the use of the portgroup.

Unfortunately there is no "foundational port" which owns the catalog skeletons, so there is no mechanism to remove them entirely from within the port system. That is, there is no port which knows about the state of other ports or can assume that if it is uninstalled it can completely remove the catalogs in question. Any suggestions there would be appreciated.

[mojca (Mojca Miklavec)]

Replying to tlockhart1976@…:

Replying to mojca@…:

I committed r144343 with the changes because that was really the last port that needed the upgrade to 5.22. But we need to figure out what's with all those failures that I'm experiencing.

You have entries in /opt/local/etc/sgml/catalog which point at files which do not exist on your system. I have the same entries, but have the files in question (e.g. /opt/local/share/xml/docbook/4.2/docbook.cat).

No, I was actually using "sudo port -t install docbook-utils". So it was MacPorts that has hidden those files.

The problem with "is not a function name" is due to a missing secondary XML or SGML catalog.

What exactly is missing and where?

Several SGML and XML ports reference these catalogs, and formerly they had a bunch of duplicate (or nearly duplicate - ugh) code which tried to manage these catalogs. A while ago I modified these to use the "xmlcatalog" portgroup to consolidate this duplicate code. I would expect that these catalogs get consistently augmented and diminished when ports are installed or removed, but extra duplicates are not detected and are not removed. I'm guessing that you have an inconsistent set of catalogs dating from before the use of the portgroup.

Unfortunately there is no "foundational port" which owns the catalog skeletons, so there is no mechanism to remove them entirely from within the port system. That is, there is no port which knows about the state of other ports or can assume that if it is uninstalled it can completely remove the catalogs in question. Any suggestions there would be appreciated.

Can you please open a new ticket describing the problem in detail, so that we can further discuss pick up from there?

If you are saying that docbook-utils is not broken (and only fails to work for me), I'll happily close this ticket, but it would be nice to keep track of potentially remaining problems.

Thanks for explanations.

[mojca (Mojca Miklavec)]

I just figured out that one ticket about "not a function name" is already opened: #44464. We might need another one about those missing ports. But I'll close this port as the transition to 5.22 has been done at least.