Hello,
it was brought to my attention that unlike in Fedora, openSUSE has taken care of the (relatively niche) area of dealing with packages' entries to what other SW consumes (directly or via transitive chain of catalogs) from /etc/xml/catalog file:
https://en.opensuse.org/openSUSE:Packaging_XML_Schemas_and_Stylesheets
What follows is a natural consideration whether it would, for once, make sense for Fedora to follow this example, for ~3 reasons:
0. less imperative, more declarative is issually somewhat more relaxed at both "produce" and "grok" directions
1. it's easy to forget about the removal part when using explicit procedural form of registering a custom catalog in pre/post scriptlets (it happened to me with upstream, thanks to the reviewer for spotting it, and actually also for pointing the openSUSE advancement in this packaging territory per above)
2. unified path for the custom catalogs to allow for immediately groking the delegations without even reviewing /etc/xml/catalog file in detail
3. sticking with what openSUSE already does means less of a wide RPM ecosystem fragmentation
Now, if this received a positive feedback, I am not sure how to go about rewriting update-xml-catalog executable from scratch vs. just adopting theirs, regarding proper license compatibility, attributions, in which package to put it, etc. But I guess, that'd be secondary, so what I want to know at this point is whether:
- such a packaging related "enablement" would make sense, with an outlook to eventually (given the proper Fedora change process if eligible here) mandate the use of this new mechanism for hooking custom XML catalogs in, perhaps to the extent that /etc/xml/catalog would be assumed immutable, with only the pre-delegated catalog eligible for changes
- there is a precedent of Fedora adopting parts of openSUSE packaging practices, like it would be the case here
Thanks
On Thu, Aug 22, 2019 at 02:44:37PM +0200, Jan Pokorný wrote:
it was brought to my attention that unlike in Fedora, openSUSE has taken care of the (relatively niche) area of dealing with packages' entries to what other SW consumes (directly or via transitive chain of catalogs) from /etc/xml/catalog file:
https://en.opensuse.org/openSUSE:Packaging_XML_Schemas_and_Stylesheets
What follows is a natural consideration whether it would, for once, make sense for Fedora to follow this example, for ~3 reasons:
A unified management of XML catalogs is very good idea. Having packaged and properly registered DTDs is is prerequisite for processing XML files an off-line environment (e.g. generating documentation from DocBook in Koji).
-- Petr
On 22/08/19 14:44 +0200, Jan Pokorný wrote:
it was brought to my attention that unlike in Fedora, openSUSE has taken care of the (relatively niche) area of dealing with packages' entries to what other SW consumes (directly or via transitive chain of catalogs) from /etc/xml/catalog file:
https://en.opensuse.org/openSUSE:Packaging_XML_Schemas_and_Stylesheets
What follows is a natural consideration whether it would, for once, make sense for Fedora to follow this example, for ~3 reasons:
less imperative, more declarative is issually somewhat more relaxed at both "produce" and "grok" directions
it's easy to forget about the removal part when using explicit procedural form of registering a custom catalog in pre/post scriptlets (it happened to me with upstream, thanks to the reviewer for spotting it, and actually also for pointing the openSUSE advancement in this packaging territory per above)
unified path for the custom catalogs to allow for immediately groking the delegations without even reviewing /etc/xml/catalog file in detail
sticking with what openSUSE already does means less of a wide RPM ecosystem fragmentation
Now, if this received a positive feedback, I am not sure how to go about rewriting update-xml-catalog executable from scratch vs. just adopting theirs, regarding proper license compatibility, attributions, in which package to put it, etc.
Also, got to realize, we'd likely want to get rid of explicit invocations of anything since it's a model use case for rpm triggers -- single path that, when changed, will provoke the correct action.
But I guess, that'd be secondary, so what I want to know at this point is whether:
such a packaging related "enablement" would make sense, with an outlook to eventually (given the proper Fedora change process if eligible here) mandate the use of this new mechanism for hooking custom XML catalogs in, perhaps to the extent that /etc/xml/catalog would be assumed immutable, with only the pre-delegated catalog eligible for changes
there is a precedent of Fedora adopting parts of openSUSE packaging practices, like it would be the case here
packaging@lists.fedoraproject.org
-
Jan Pokorný -
Petr Pisar