On 31 August 2016 at 04:58, dani <dani@xxxxxxxxxxxx> wrote: > > > On 29/08//2016 22:23, Jason L Tibbitts III wrote: >>>>>>> >>>>>>> "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< > > 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@xxxxxxxxxxxxxxxxxxxxxxx > https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > -- Stephen J Smoogen. _______________________________________________ epel-devel mailing list epel-devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
