On 31 August 2016 at 04:58, dani <dani(a)letai.org.il> wrote:
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.
No that is not the main argument at all. There isn't an argument here.
The issue is that your scheme needs to be fully written up and then
reviewed and approved by the Fedora Packaging Committee and FESCO.
This is what every other packaging scheme (for everything from SCL to
ruby to java) has to do.
No one is going to write up the policy for you. No one is going to
champion it for you. Not because we are against what you are doing but
because most of us have 20 other jobs that we have to get done at any
other time and our 'free' time is very limited.
I'm only asking for a clear policy regarding multiversion
packages, which
would define clear guidelines on any submission requests.
_______________________________________________
epel-devel mailing list
epel-devel(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraprojec...
--
Stephen J Smoogen.