On 29/08//2016 22:23, Jason L Tibbitts III wrote:
>>>>> "d" == dani <dani(a)letai.org.il>
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<
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.
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.