Jerry James wrote:
It's up to the maintainer. It is certainly preferable for the maintainer to follow upstream but this can mean different thing in different packages.In the section entitled, "Multiple packages with the same base name", the package naming guidelines state that one package should use the base name with no version, and all others should include the version in their names. I have two questions about this. First, is the intent that the most recent version of the package be the one with no version number, or is that left up to the maintainer(s) to decide? If the latter, and the maintainers decide to make an older version be the one with no number, what should happen when that package is retired? I started thinking about this in conjunction with the call for help with the Java guidelines. We currently have an "asm2" package, because there used to be an "asm" package. The name of the upstream project is just "asm", so the "asm2" package is currently violating the naming guidelines.
Second, is the use of the word "compat" in the name, as in "compat-libstdc++-33", considered mandatory, desirable, undesirable, something else?
Compat packages are generally different from what is currently documented in the naming guidelines. There was talk of writing guidelines for compat- packages but no one has done that yet.
The guidelines are covering things like gtk and gtk2 where you want to have two parallel versions of a library where either can be built against. compat- packages are generally runtime-only. I don't know if java has the separation of devel bits and runtime bits so I don't know if this makes sense for them.
So, running with the previous example, should we rename "asm2" to "compat-asm2" and make the upcoming "asm3" package be named "asm"?
Up to the maintainer whether to use asm for the latest or the earliest package. Whether to use compat- needs a better understanding of java in general and what you want to enable with the asm package in particular.
-Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
