[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

[dani]

On 29/08//2016 22:23, Jason L Tibbitts III wrote:

"d" == dani   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.




smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

[dani]

  
  
On 27/08//2016 01:38, Neal Gompa wrote:

  On Fri, Aug 26, 2016 at 6:24 PM, dani  wrote:

  

I think it is high time to rethink the single version of a package policy,
and come up with some scheme that would allow for any package to maintain
multiple versions in a consistent manner.

  
  
We wouldn't even be the first distro to wind up discarding that
policy. Both openSUSE and Mandriva did the same many years ago. That
led to the restructuring of the packaging to the current form openSUSE
and Mageia have[1][2].

[1]: https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines

They use alternatives which is wrong - it forces a default for the
entire system, rather than on a per-user basis.
See mpi-selector for a better approach - it allows both a system
wide and a user default, the later taking precedence over the
former.
It was deprecated in favor of environment modules, BTW.

  
[2]: https://wiki.mageia.org/en/Libraries_policy




This only handles major version numbers AFAICT, and devel packages
with versions in the names are considered an exception, which in my
opinion is not a good approach.

Under my scheme there can be multiple devel packages, each linked to
it's "main" package by means of a standardized prefix.
I use e.g. gcc6.1.1-gcc gcc6.1.1-gcc-c++ etc. for the entire suite,
so there are no name conflicts as well as no path conflicts, and
makes it easy to install/remove an entire version by the use of yum
install gcc6.1.1\*

This works for me, but I'm aware my use case is quite limited and
might have drawbacks which make it unsuitable for epel.

I believe scl uses a postfix scheme which I personally find less
convenient, but I could adopt that easily if required.

[1]:
http://rpm.pbone.net/index.php3/stat/45/idpl/22601613/numer/1/nazwa/mpi-selector
  




smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

[dani]

  
  



On 26/08//2016 21:18, Stephen John
  Smoogen wrote:


  On 26 August 2016 at 12:58, Stephen John Smoogen  wrote:

  
On 26 August 2016 at 06:00, Daniel Letai  wrote:


  

On 08/25/2016 11:40 PM, Kevin Fenzi wrote:

Perhaps you could explain exactly what you want to propose here again?
Just epel6? or 7 as well? Do you have co-maintainers in case you get
busy, etc?

I propose adding several gnu packages (namely gcc, binutils and gdb) with
versions following those supplied by fedora, specifically for epel6, but
possibly for epel7 if requested.

This could hold a pattern such as /opt/gnu/[gcc|binutils|gdb]// to
allow several version to co-exist.
I don't have any co-maintainers, but I mainly get busy in my day job, which
happens to be the reason I maintain those packages.




OK there were multiple reasons there were reservations for this:

1) /opt/gnu (and many other /opt/*) names are already in use by many
site admistrators. Putting our packages in there and over-writing
locally compiled apps is going to cause problems. [Remember rpm will
overwrite /opt/gnu/gcc/5.0/bin/gcc if it wasn't in the rpm db before
hand without any report of a conflict.]

  
  
In reading some of the FESCO tickets, we can't use /opt/gnu because we
are not the GNU organization.
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html

We would need to use the /opt/fedora or go through the process of
becoming an entity that the LANANA.org people would recognize.

I think /opt/fedora would be fine, but it would require an
additional level to allow for better flexibility, something like
/opt/fedora/epel[6?]/gcc/5.3/...
If possible, /opt/epel/gcc/... is more intuitive, but might require
registration ( I'm not familiar with any other "epel" out there that
might contest the use of "epel" as a new provider).
This would also allow for differing python version
(/opt/epel/python/[2.7,3.0,3.4...])  or any other multi-version
package some might wish to maintain.

I realize this is not the fedora way, to maintain multiple version
of the same package, and over the years this had led to some
inconsistencies in naming - python might be the most known example,
but other packages exists which had to do with all sort of *-compat
or name kludges.

I think it is high time to rethink the single version of a package
policy, and come up with some scheme that would allow for any
package to maintain multiple versions in a consistent manner.
gcc is just a single example where such a need exists. Perl, python
and any other tool that breaks api between versions is of course a
candidate.

SCL, while apparently solving this issue, seem to break the modular
approach to software delivery that is rpm - you have to use fixed
versions provided by an scl suite for the entire tooling, rather
than upgrading or using tools from different versions as long as
they are compatible.
  




smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Adding the devtoolset repo for EPEL builds

[dani]

When I proposed importing gcc-5 to EPEL6 back in 04/2016 ( 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/F5JXEYPKQY77NRBCL4MNUBS3K2YYBBTU/ 
) the response was an unequivocal no, EPEL does not install to /opt/ , 
so it dies right there.


Now you are proposing the same ( devtoolset/scl installs to /opt except 
for the wrapper call) but using a scheme that is somewhat less 
convenient (In scl the binutils and gcc have to be coupled, and as noted 
the imported gcc suite is incomplete), much less frequent (the most 
updated version is gcc-5.2, while I maintain both gcc-5.x and gcc-6.1), 
and much less complete (I import everything but gcc-gnat, while 
devtoolset4 only has gcc,gcc-c++ and gcc-gfortran. No gcc-objc, no 
gcc-go, no cpp, and none of the libs (cilk, gccjit, atomic, asan etc...).


I'm still building and maintaining both gcc and bintutils for my own 
purposes, which are based off of fc24 srpms, and with optionally gcc-c++ 
specs file hardcoded to use binutils tools at the new prefix so use of 
env-modules is not required.


I'm just wandering why the different treatment - the automatic knee-jerk 
reaction of dismissal to a newbie proposal vs. accepting the exact same 
proposal (although wrapped so it's less convenient to use) when it comes 
from someone else.



On 25/08//2016 06:59, Dave Johansen wrote:
On Wed, Aug 24, 2016 at 5:28 PM, Kevin Fenzi > wrote:


On Wed, 24 Aug 2016 16:43:31 -0600
Dave Johansen mailto:davejohan...@gmail.com>> wrote:

> On Wed, Aug 24, 2016 at 4:22 PM, Kevin Fenzi mailto:ke...@scrye.com>> wrote:
>
> > On Tue, 23 Aug 2016 14:21:24 +0100
> > Karanbir Singh mailto:mail-li...@karan.org>> wrote:
> >
> > > On 22/08/16 18:30, Jason L Tibbitts III wrote:
> > > >> "DJ" == Dave Johansen mailto:davejohan...@gmail.com>> writes:
> > > >
> > > > DJ> devtoolset is designed to do all of this and is already
> > > > DJ> done, so it seems that the only advantage to putting it in
> > > > DJ> EPEL itself would be to reduce the number of repos during
> > > > DJ> build time.
> > > >
> > > > So is devtoolset something I get access to as a CentOS user?
> > > > How do I build these packages myself (i.e. in mock)?
> > >
> > > you should be able to 'yum install centos-release-scl' on a
CentOS
> > > Linux machine and get access to all the SCLs
> >
> > Yeah, but if we enable that for EPEL builds, we are going to
get all
> > SCLs right? So, people could start depending on them at runtime
> > instead of just install time.
> >
> > I'm not opposed to devtoolset, but I don't think we want to allow
> > runtime scls without actual scl guidelines.
> >
>
> I seem to remember that Fedora didn't allow SCLs because there was
> some compatibility problem or something of the sort. Do you know the
> details or what the current state is?

It's not a compatibility problem. It's lack of guidelines.

> Also, RedHat has been pushing devtoolset pretty hard. The
response to
> a few bugzillas has even been "use devtoolset because the issue is
> fixed there and we're not going to fix the system gcc/libc/etc". So
> it seems like allowing SCLs in Fedora/EPEL makes sense and fits with
> the direction of RHEL in general.

As I noted, I'd probibly be for devtoolset because the guidelines
would
be pretty simple. Just do X Y and Z in your spec, build as normal and
users wouldn't see any run time dep on it.

It gets weird where other SCL's come in. Can your package require say
postgresql from SCL instead of the rhel one? If so, would our
users all
be able to install that? What happens if two packages need different
SCL versions? Can SCL's depend on each other? Can you make a package
thats an SCL? we have no guidelines for that, and just saying "do
whatever you want" is likely to cause mass confusion and make everyone
miserable.


I agree that how to handle SCLs can get really mess really fast, but a 
lot of projects are jumping on the "modern C++" bandwagon and allows 
devtoolset is low risk, easy to do and enables a lot of packages to be 
built with EPEL that otherwise wouldn't be.


Basically, I think that figuring out how to handle SCLs is a long term 
issue that will take some serious work, but coming up with some simple 
policies that allow it to be used in EPEL is something that should be 
well within the realm of the possible.



___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org





smime.p7s
Description: S/MIME Cryptographic Signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproje

[EPEL-devel] Import fedora gcc-5.3 in EPEL6

[dani]

Hello list,

I've built an environment-modules based gcc-5.3.1 for RHEL6 that lives 
side-by-side with vendor packages - it installs to /opt/ and has a 
name{version} scheme to avoid conflicts, which I'd like to include in EPEL6.

In accordance with the guidelines 
(https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Still_unsure_if_a_package_is_fine_for_EPEL.3F)
 I'm asking here if this is appropriate or, if not, how can I modify it so 
gcc-5 can make it into EPEL.

I can provide a working srpm for both binutils2.26 and gcc5.3.1 (the binutils 
is required, and also builds to /opt and enabled via modules).

Thanks in advance
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org