On 29/08//2016 22:23, Jason L Tibbitts III wrote:
There is no policy for multiversioning, which results in an inconsistent packaging scheme for each multi-version provided, with some relying on alternatives, others add new sub-hierarchy to /usr and almost none consider allowing for other versions other than their own."d" == dani <dani@xxxxxxxxxxxx> writes:d> I think it is high time to rethink the single version of a package d> policy, and come up with some scheme that would allow for any package d> to maintain multiple versions in a consistent manner. We don't have such a policy. At least Fedora doesn't. In fact, adding another version of an existing package doesn't require a pass through the review process. The packages just need to not conflict and be named appropriately. Dealing with the names of binaries is left up to the packager. - J<
Alternatives forces system-wide defaults, with the different versions not easily accessible, or used as a group. SCL solves that issue, but must be applied on a full suite basis only, and only at the version points provided by any scl repo.
As mentioned, it doesn't exists for other architectures, the way native fedora rpms do.
As far as i could tell, the main argument against my scheme was usage of /opt, yet it is approved for scl, despite scl's limitations.
I'm only asking for a clear policy regarding multiversion packages, which would define clear guidelines on any submission requests.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ epel-devel mailing list epel-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
