[EPEL-devel] Re: Packaging a newer singularity-ce as singularity-ce4

[Stephen Gallagher]

On Fri, Jan 26, 2024 at 8:08 AM David Trudgian via epel-devel
 wrote:
>
> Hi all,
>
> I’ve had some discussion with Jonathan Wright elsewhere about the topic of 
> this message, but wanted to verify my understanding is correct before I 
> embark on it, and thought I’d do so on list.
>
> singularity-ce is currently packaged at v4.0.3 in Fedora Rawhide, and 
> v.3.11.5 elsewhere (Fedora releases and EPEL).
>
> We want to make a v4 available to EPEL users, as many would be interested in 
> it, but I wouldn’t consider it a compatible update because there are some CLI 
> changes, and small behaviour changes.
>
> My understanding is that in order to provide a 4.x in EPEL, without any 
> incompatible update happening for users:
>
> 1) I create a new package, singularity-ce4, to package the 4.x version. In 
> rawhide, this will be the same as the singularity-ce package currently in 
> rawhide, but needs new package review etc.

Creating a versioned package does NOT require a new review[1], though
if you feel that packaging changes are going to be large enough to
warrant one, you may still request it.

>
> 2) For rawhide / upcoming f40 *only*, the new singularity-ce4 package will 
> provide/obsolete singularity-ce as it is the same thing … and singularity-ce 
> can be retired in rawhide.

> 3) When singularity-ce4 is added to EPEL it will *not* provide/obsolete 
> singularity-ce, but a message can be added to %post to inform people about 
> the availability of v4.

Do not do this. %post messages are really only intended to inform
users of failures and, frankly, no one reads them until something has
gone wrong. Even then, it's only going to be the sysop for the machine
that sees it, who may not be the person who deals with Singularity.

I don't know anything about Singularity, but if it has a user
interface of any kind (like the CLI), what you might want to do is add
a wrapper around it that prints your message. That's much more likely
to be viewed by the people who would care.

> At some point in the future, if 3.x is no longer maintainable for good 
> reason, then the incompatible update procedure can be pursued to make 
> singularity-ce4 provide/obsolete singularity-ce in EPEL 7/8/9 - and 
> singularity-ce is fully retired. EPEL 10 will only get singularity-ce4.

Is v3 still supported upstream today? If not, you probably want to
make the message above a deprecation notice and add an EOL date.


> Apologies for the multiple complex queries lately. I really appreciate your 
> guidance!
>


[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Bundling newer 3rd party binaries than are packaged separately

[Stephen Gallagher]

On Tue, Jan 23, 2024 at 11:58 AM David Trudgian via epel-devel
 wrote:
>
> Hi all,
>
> I currently package singularity-ce for Fedora and EPEL.
>
> Upstream, we bundle current versions of squashfuse and conmon with our source 
> and own binary packages… because many distros package versions that are too 
> old to work with SingularityCE, and users installing our upstream binary 
> packages just want them to work.
>
> In Fedora & EPEL packaging I disable the building of the bundled squashfuse 
> and conmon in the spec file, and we rely on the distro’s squashfuse and 
> conmon packages.
>
> This is fine with Fedora, and has been okay up until now for EPEL. However, I 
> want to move forward with packaging SingularityCE 4.x for EPEL and there we 
> need a newer squashfuse than is available in EPEL7. Given our user base, 
> leaving EPEL7 without the update wouldn’t be popular, even if it is 
> approaching EOL.
>
> I wanted to verify if whether it's acceptable to bundle a newer squashfuse in 
> the SingularityCE package as a binary under our libexec dir, given that an 
> older squashfuse is provided by an existing squashfuse package? If so, are we 
> required to declare the bundling in the spec file, as we are doing for 
> bundled go deps in the spec?
>
> What has given me pause is reviewing the bundling guidelines at 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling - where 
> it seems, at least for libraries, that a `Provides: bundled() = 
> ` is required… and it’s not really clear to me whether the 
> discussion there about libraries can be directly applied to *executables* 
> that might be bundled?
>
> I note that the apptainer spec / package is already bundling a newer 
> squashfuse binary into its libexec dir without a corresponding Provides: … so 
> perhaps it’s fine to go ahead? Apologies if I have missed prior discussion on 
> this.
>
> https://src.fedoraproject.org/rpms/apptainer/blob/rawhide/f/apptainer.spec
> https://packages.fedoraproject.org/pkgs/apptainer/apptainer/epel-7.html#files
>
> And it looks like their next release might be bundling a newer fuse2fs than 
> is in the distro e2fstools package too, plus a newer fuse-overlayfs than is 
> in the distro package:
>
> https://src.fedoraproject.org/rpms/apptainer/blob/rawhide/f/apptainer.spec
> https://packages.fedoraproject.org/pkgs/apptainer/apptainer/fedora-rawhide.html#files

If you are bundling any software, you need to `Provides:
bundled(software)`. This is so we can easily locate affected packages
when e.g. a security issue necessitates fixing it.

Also, since it wasn't clear from your text above: It's (generally)
alright under these circumstances to bundle the extra packages, but
you need to meet certain requirements:

* The code that you're bundling still has to be built in Fedora. That
probably means compiling it as part of your SingularityCE build. You
may not ship code that was compiled somewhere else (e.g. upstream).
* If you are shipping executables exclusively for use with your
package, make sure they are properly namespaced in
/usr/libexec/singularityce (or similar). This is to ensure that no
other package accidentally tries to use your bundled version.
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Big Node.js jump coming to EPEL 7

[Stephen Gallagher]

On Mon, Jan 17, 2022 at 7:21 PM Stephen Gallagher  wrote:
>
> Last week, I retired the `nodejs` package from EPEL 7 because it was
> (I believed) stuck on Node.js 6.x due to insufficient dependency
> support. Apparently, this broke a few things like uglify-js[1], so I
> spent today looking into whether I could get Node.js 16.x to work (the
> latest LTS release) and it turns out that I can indeed bludgeon it
> into working. I have a COPR[2] with a build of Node.js 16.x for EPEL 7
> available to try while I await releng unretiring[3] the package.
>
> Please note: Node.js 16.x is a SIGNIFICANT version jump. It is very
> probably that some of your Node packages may not work properly against
> it. I urge anyone who is maintaining any such packages in EPEL 7 to
> try them out against the aforementioned COPR prior to my building it
> in EPEL proper.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2041022
> [2] https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs_epel7/
> [3] https://pagure.io/releng/issue/10541


This is now built and on its way to the epel-testing repository:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-bf9c411793
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Big Node.js jump coming to EPEL 7

[Stephen Gallagher]

Last week, I retired the `nodejs` package from EPEL 7 because it was
(I believed) stuck on Node.js 6.x due to insufficient dependency
support. Apparently, this broke a few things like uglify-js[1], so I
spent today looking into whether I could get Node.js 16.x to work (the
latest LTS release) and it turns out that I can indeed bludgeon it
into working. I have a COPR[2] with a build of Node.js 16.x for EPEL 7
available to try while I await releng unretiring[3] the package.

Please note: Node.js 16.x is a SIGNIFICANT version jump. It is very
probably that some of your Node packages may not work properly against
it. I urge anyone who is maintaining any such packages in EPEL 7 to
try them out against the aforementioned COPR prior to my building it
in EPEL proper.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2041022
[2] https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs_epel7/
[3] https://pagure.io/releng/issue/10541
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Pre-release EPEL

[Stephen Gallagher]

On Thu, Sep 16, 2021 at 10:11 AM Neal Gompa  wrote:
>
> On Thu, Sep 16, 2021 at 9:38 AM Thomas Stephen Lee  wrote:
> >
> > Hi,
> >
> > Thanks to people on the CentOS mailing list.
> > We managed to get CentOS Stream 9 pre-release with updates working on a VM.
> > Is there also a pre-release version of EPEL 9 we can use?
> >
>
> Not just yet, I'm hoping that'll be soon...

The EPELves are working as hard as they can, stay tuned!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: EPEL8 conflict policy

[Stephen Gallagher]

On Wed, Apr 8, 2020 at 11:26 PM James Cassell
 wrote:
>
>
> On Wed, Apr 8, 2020, at 9:20 PM, Orion Poplawski wrote:
> > There does not appear to be an explicit conflict policy for EPEL8:
> >
> > https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F
> >
> > I got a report against python3-s3transfer and python3-botocore
> > conflicting with the CentOS 8 HighAvailability repo. No idea if this is
> > an issue or not: https://bugzilla.redhat.com/show_bug.cgi?id=1821630
> >
> > It looks like we have avoided conflicts with the "ha" repos in the past,
> > and I can enable the rhel-8-for-x86_64-highavailability-rpms repo on my
> > RHEL8 developer license machine so it does seem available to everyone.
> >
>
> It's not available to everyone. It's a paid add-on. My understanding is that 
> EPEL avoids conflicting only with the BaseOS, AppStream, and CodeReady Linux 
> Builder repositories.
>
> c.f., ansible, which is more widely available than HA, but also carried in 
> EPEL.


One addendum to this: EPEL 8 *may* provide conflicting content in
non-default module streams (since enabling these is always opt-in).
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: What is the proper way to handle python3 python36 in RHEL7

[Stephen Gallagher]

On Tue, Mar 31, 2020 at 12:51 PM Erinn Looney-Triggs
 wrote:
>
> I am trying to build a package for RHEL 7 and RHEL 8 that depends on an EPEL 
> (for RHEL 7) package python36-dbus the requires section goes like so:
> Requires: %{python3}
> Requires: %{python3}-dbus
>
> This puts in a requirement for python3-dbus for RHEL 7 which doesn't exist, 
> the package is actually python36-dbus, however short of a conditional saying 
> if rhel 7 then package name is python36-dbus is there a clean and scalable 
> way to make sure the package version is correct?
>
> I am looking into python3_pkgversion macro but that doesn't seem to be 
> correct either. Does anyone know how I should do this now with a single spec 
> file for both RHEL 7 and 8 that doesn't contain a conditional expression?

See https://bugzilla.redhat.com/show_bug.cgi?id=1812665

There's a bug in the macros.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

[Stephen Gallagher]

On Tue, Feb 25, 2020 at 5:05 PM Troy Dawson  wrote:
...
> While I agree that we should be very careful with this, I do not
> believe it should be completely off the table.
> I believe it should be permissible with the EPEL Steering Council's
> blessing, but not otherwise.
> Case in point is libssh2.
> It was provided in the original RHEL 8.0 virt module, but not since
> then.  It's causing all sorts of grief, especially when people are
> using both RHEL8 (where you see it) and CentOS8 (where do you don't).
> There is a bugzilla ticket in with the team, but it looks like it's
> going to take a while before a fix get's implemented.
> My proposal is to create a libssh2 module, with a higher NEVR than in
> that original RHEL8 module.
>

OK, I hadn't considered that aspect and I agree with you. Under
*carefully controlled and approved circumstances*, we can permit
updating a package from a different module.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

[Stephen Gallagher]

On Tue, Feb 25, 2020 at 3:57 PM Matthew Miller  wrote:
>
> On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote:
> > Consider:
> >
> > 1. foo rpm that is in the RHEL baseos. It's not in any module.
> > Can epel make a foo (non default) module that overrides it?
> >

This is safe from a technical perspective and should be fully endorsed by EPEL.

> > 2. foo rpm that is in a RHEL default module.
> > Can epel make a foo (non default) module that overrides it?
> >
> > 3. foo rpm that is in a RHEL non default module.
> > Can epel make a foo (non default) module that overrides it?


2 and 3 are safe from a technical perspective with one major caveat:
they can only be replaced by an alternate stream of *the same module*.
This is because otherwise both RPMs will be visible to the package
manager and the behavior is complicated. I'm actually not sure which
way it will break; either both sets of RPMs will be visible to the
transaction and you'll end up with the highest NEVRA, regardless of
which one you intended to get; or both modules will suppress each
other and neither of their RPMs will be available. I think it's the
first case, but either way it should be avoided.

This is also why we (Merlin and I) determined that the `epel-` prefix
was a non-starter; this case makes that too risky.

If we want to find a way to highlight where a stream is coming from to
disambiguate EPEL streams from RHEL streams, I think we need to do
some UX work on `dnf module list` to display the source repo for each
available stream in a meaningful way.


Lastly, I think Petr Pisar is pretty much spot-on with his explanation
of the EPEL -> RHEL transition; we need to make sure that the
V(ersion) field in the module stream's NSVCA is higher for the new
RHEL version than it is in EPEL, similar to what we do with
non-modular packages today. In that case, DNF will just select the
RHEL version of the stream as an update to the EPEL version of the
stream and things should work out fine. The "gotcha" is those cases
where the EPEL maintainer doesn't know that a RHEL update is coming
and inadvertently updates to a higher version than RHEL ends up
delivering. As this case is basically identical to the non-modular RPM
case, the same mitigation strategies should work (either drop the
conflicting module contents from the repo or else release a higher
version in RHEL as an errata).
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: epel8-playground and centos-stream?

[Stephen Gallagher]

On Thu, Oct 3, 2019 at 10:05 AM Matthew Miller  wrote:
>
> On Tue, Sep 24, 2019 at 02:54:26PM -0700, Kevin Fenzi wrote:
> > After the announcement today of centos-stream, I wonder if it would make
> > sense to move epel8-playground to build against that instead of the
> > latest rhel8 release?
>
> This is something we're talking about at the CentOS Stream kickoff meeting.
> As EPEL exists today against RHEL and CentOS Linux rebuild, there's a lag
> time problem when there are surprising RHEL updates -- usually fixed in a
> few days but sometimes weeks. With CentOS Stream, hopefully there will be no
> surprises, but the gap between CentOS Stream and RHEL will be always there.
>
> I think if we changed EPEL Playground to build against CentOS Stream, we'd
> just move the bifurcation problem rather than solving it. I kind of think we
> need _both_ epel8 and epel8-playground built against both RHEL and CentOS
> Stream. But I'd love to hear better ideas.
>

I'd suggest a middle-ground: we normally build against the latest RHEL
8 minor release. Once the RHEL 8.x+1 *beta* is released, we change
epel8-playground to build against CentOS stream until the GA release.
We can also potentially run a mass-rebuild at this time to help
identify issues early.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: epel8-playground and centos-stream?

[Stephen Gallagher]

On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa  wrote:
>
> On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi  wrote:
> >
> > After the announcement today of centos-stream, I wonder if it would make
> > sense to move epel8-playground to build against that instead of the
> > latest rhel8 release?
> >
> > It would make playground less usefull for testing new radical changes
> > against the current stable point release, but on the other hand, the
> > centos stream will become the next stable point release, so it would
> > allow people to test against that and get changes ready that they could
> > then push in after the next stable point release landed?
> >
> > What do folks think? Bad idea, good idea?

I think that makes good sense; it will provide a guarantee of early
notice when an upcoming RHEL release might introduce a problematic
change (intentionally or otherwise) and provides Red Hat with feedback
and an opportunity to fix it before RHEL releases. It will also make
our minor release merge windows easier, since we should not get any
major surprises hitting only at Beta or GA.

If we decide *not* to do this, I think we need to at least have a
policy of updating the buildroot for EPEL8-playground to include the
RHEL minor release beta tree as a lesser version of the same process
as above.

> >
>
> If we do that, then we should rename `epel8-playground` to `epel8-stream`...
>
> I'd like it to work the same way that epel7 worked. And that means no
> more automatic provisioning epel8-playground for epel8 stuff. And
> package.cfg should become optional.

I disagree, mostly because I think we want there to be minimal
friction to supporting both branches. If we retain the package.cfg,
then what we're getting
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Modularity Policy Discussion for EPEL 8.1

[Stephen Gallagher]

On Fri, Aug 23, 2019 at 1:56 PM Stephen Gallagher  wrote:
>
> As you know, we delayed support of Modularity in EPEL (called
> Application Streams in RHEL) until 8.1 while we worked out some
> remaining issues. Some of those issues were technical, but we have a
> few others that will come down to policy. In particular, EPEL has to
> deal with something Fedora does not: the possibility that it could
> come into conflict with streams from the official Red Hat Application
> Streams.
>
> I'm going to try to enumerate in this email some of the cases I can
> think of that might need attention, as well as providing my
> recommendations for what policy we should set in EPEL.
>
> Case 1: EPEL ships a module "foo" with stream "baz" (aka "foo:baz").
> This is an alternative stream to RHEL AppStream, which ships
> "foo:bar". In a new minor release, RHEL AppStream starts also shipping
> "foo:baz".
>
> Case 2: EPEL ships a module "foo:baz". RHEL AppStream does not ship
> the module"foo" at all. In a new minor release, RHEL AppStream starts
> also shipping "foo:baz".
>
> Case 3: EPEL ships a module "foo:baz". RHEL AppStream does not ship
> the module "foo" at all. In a new minor release, RHEL AppStream starts
> also shipping "foo:bar".
>
...
>
> So lets's break these down. The first three cases are all very
> similar. They address the situation where we have both RHEL and EPEL
> attempting to own the same name within a namespace (module). My
> recommendation here is that we require EPEL module streams to be
> prefixed with "epel-". Then, even if RHEL AppStream starts shipping a
> stream of the same name, there will be no namespace collision. There
> is another benefit as well: it will be easy to tell at a glance
> whether a particular stream is from RHEL AppStream (and therefore
> supported by Red Hat) or if it comes from EPEL, with only volunteer
> community support.
>

Since sending this, I've had numerous conversations elsewhere (IRC,
conference calls, https://pagure.io/Fedora-Council/tickets/issue/272,
etc.) discussing this and we've come to the determination that my
first recommendation (prefixing with "epel-") is probably not the
right appproach. In particular, it has the following downsides:

To quote from my comment in the aforementioned ticket:


Right now, if EPEL is permitted to use the same stream names as Fedora
(in other words, things like nodejs:12 as opposed to nodejs:epel-12),
then it becomes very easy for packagers to build for EPEL.
Specifically, the existing Module Stream Expansion functionality will
just go ahead and start building for EPEL 8 once that platform appears
in the PDC database. And, in most cases, it will build just fine. This
also moves us from an opt-in to maintaining EPEL packages to an
opt-out to maintain EPEL Modules.

There are some downsides to this: we need to have tooling and policies
in place to address what happens if RHEL releases a module stream of
the same name. @psabata and I generally agree that we should treat
this much the same way as with non-modular packages, which is to say
that RHEL would take over ownership of the stream (dealing with the
version number appropriately so that upgrades are trivial).

Forcing EPEL packages to use a namespaced stream has other advantages
and disadvantages. The obvious advantage is that it's very clear to
the user when they have selected an EPEL stream (thus cutting down on
support calls to Red Hat about EPEL content). However, this comes with
considerable disadvantages:

* Module Stream Expansion won't work because it creates all of its
builds with the same stream name. Writing specialized code to detect
builds for EPEL 8 and change this mid-flight would be complicated and
error-prone. (Particularly in the straw-man case of a module that's
build once, run anywhere because it's statically linked, like the rust
packages.)
* If the stream has dependencies on another module stream (e.g. meson
depends on ninja), then all of those stream names need to be adapted
to include the EPEL prefix as well. This is, again, probably doable,
but it's a considerable amount of work with no guarantees that it will
succeed.
* If we want to do this anyway, without making changes to Module
Stream Expansion, it means that the module becomes an entirely
separate stream in dist-git that is maintained separately. That gets
us back to opting-in to EPEL 8, rather than opting out. We'll end up
with less content in that case.



So, with this in mind (and with the agreement of the Fedora Council),
I think we ought to proceed with EPEL packages following the same
stream naming guidelines as Fedora and we (Red Hatters) will establish
a procedure for "taking over" a stream name if and when that is
appro

[EPEL-devel] Re: Modularity Policy Discussion for EPEL 8.1

[Stephen Gallagher]

On Mon, Aug 26, 2019 at 4:33 AM Petr Pisar  wrote:
>
> On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote:
> > So, I see the following options for how to handle default streams in RHEL 8
> >
> > Option 1: We disallow assigning default streams at all within EPEL 8.
> > This will protect us against a future change where RHEL wants to set a
> > default. Additionally, it means that all EPEL modules are explicitly
> > opt-in and so we don't ever surprise anyone.
> >
> > Option 2: We allow making EPEL streams the default stream if RHEL does
> > not currently provide a default stream. We set strict policy regarding
> > what a default stream may contain (such as "must not replace any
> > package provided by RHEL 8"). If RHEL later decides to set a default
> > for this stream, the RHEL release engineering must ensure that the
> > `data.version` value is higher than what EPEL 8 carries.
> >
> > I'm somewhat more in favor of Option 1 here, mostly because it
> > minimizes the chance of conflicts and ensures the opt-in nature of
> > EPEL. But I'm willing to hear counter-arguments.
> >
> I don't like the Option 1. It makes adding modularized packages into a build
> root impossible. Efectivelly forcing everbody to modularize everything or
> nothing. That's exactly the deficiency the modularity has in Fedora and does
> not have in RHEL. The Option 1 makes the modularity in EPEL terrible as in
> Fedora.


I assume you mean "adding modularized packages into a non-modular
buildroot" here. You're right, the result here would be that you could
only use RHEL BaseOS + RHEL Default streams in your buildroot or else
make a module stream.

I disagree with "makes the modularity in EPEL terrible as in Fedora",
however. Fedora's situation went awry because we *didn't* put the
appropriate restrictions/safeguards into place around default streams.
This is a policy mistake that we're still trying to fix (it's been
difficult, but I think we're getting close).

>
> Example: RHEL has two perl streams:
>
> perl:5.24
> perl:5.26 [d]
>
> You can add a non-modular perl-Foo package into EPEL bacause EPEL magically
> adds perl:5.26 into the build root.
>
> If you add a perl-Foo module into EPEL, you won't be able to set a default
> stream, hence you won't be able to have it in the build root and therefore you
> won't be able to add a non-modular perl-Bar package that requires a perl-Foo
> module component into EPEL.
>
> The only solution would be either add perl-Bar as a module, or not add
> perl-Foo as a module. If you go the second path (i.e. no modules), it means
> you won't be able build none of the packages for the non-default streams (i.e.
> perl:5.24).

Well, another thing to be aware of is that we want to avoid the "every
package has a separate module" situation, because that way lies
madness and combinatorial explosion.

What would be best is if we look at this from top-down, rather than
bottom-up. (Or, put another way: let's solve the problem the user
cares about).

Users as a general rule do not care which libraries they have. They
care that the application they want to run is available to them.

Let's take a made-up example of a package called MyApp that is capable
of running atop either Perl 5.24 or Perl 5.26. As a user, my goal is
to run this app to meet a business need.
MyApp has two dependencies: MyLibrary and MyFramework. MyFramework and
MyLibrary both also depend on MyPlatformLib.
MyApp, MyLibrary, MyFramework and MyPlatformLib are all compatible
with both Perl versions.

Looking at that dependency structure, I'd probably opt to create two modules:

1) A MyFramework module stream (we'll say "1.0") that builds both
MyPlatformLib and MyFramework and lists the artifacts produced by
*both* of those SRPM builds as API for the module. This module stream
would have its module dependencies set for both perl:5.26 and
perl:5.24. The result would be a MyFramework stream built in two
contexts, one for each Perl version.
2) A MyApp module stream (We'll say "rolling") that builds both
MyLibrary and MyApp and lists only the artifacts from MyApp as API for
the module (implying but not *enforcing* that the MyLibrary carried in
this stream should not be treated as public, stable API). This module
stream would have its module dependencies set just for
`MyFramework:1.0`.

In this case, `yum install MyApp:rolling/someprofile` would install
the "someprofile" profile of the "rolling" stream of "MyApp", pulling
in the MyFramework module for whichever Perl version is enabled (or
default) on the system.

Furthermore, with this layout, when Perl 5.28 comes out, you will only
need to rebuild MyFramework so that it creates a context that works
with perl:5.28 and MyApp will 

[EPEL-devel] Re: Modularity Policy Discussion for EPEL 8.1

[Stephen Gallagher]

On Fri, Aug 23, 2019 at 5:49 PM Kevin Fenzi  wrote:
>
> On 8/23/19 10:56 AM, Stephen Gallagher wrote:

...

> > For default profiles, we have some options as well:
> >
> > Option 1: We disallow setting default profiles for EPEL streams. Pros:
> > no risk of conflict with RHEL, should they now or in the future
> > provide defaults for some streams of this module. Cons: `yum module
> > install foo[:bar]` would not work (they would need to do `yum module
> > install foo[:bar]/profilename`) and would likely irritate users.
> >
> > Option 2: We allow setting default profiles for EPEL streams. We take
> > advantage of the defaults merging logic and ensure that if we need to
> > supplement RHEL AppStream's defaults content, we must ship a
> > modulemd-defaults document of the same `data.version`. This will allow
> > them to be merged cleanly. Pros: Optimum user experience (they get the
> > default profiles installed when they use the simplified install
> > command). Cons: We need to constantly monitor each RHEL AppStream
> > release and ensure that we aren't ever overriding (or being overridden
> > by) RHEL.
> >
> >
> > I think Option 2 is the better choice here (fewer angry users is a
> > good thing), but I worry a bit about the maintenance burden of keeping
> > track of the `data.version` values and ensuring they stay in sync. I
> > think we can probably automate a good deal of this, though.
>
>
> Yeah, I would like to do 2 also if we can manage to make it mostly
> automated.
>

So, after discussing things at today's Modularity WG meeting, we've
decided to make a breaking change to libmodulemd's merging logic to
solve this much more cleanly. Full details are in
https://github.com/fedora-modularity/libmodulemd/issues/368

With that change in place, Option 2 becomes the obvious correct
choice, since we won't have to worry about the monitoring of the
`data.version` values.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Modules and EPEL8-Playground

[Stephen Gallagher]

As we plan EPEL 8.1 with support for Modularity/Application Streams,
we will undoubtedly encounter numerous tricky questions that warrant
public input. The first of these is this: where do modules fit into
EPEL 8 Playground?


I see three possibilities for how this can be done:

1) We create two "platform" modules: "platform:el8" and
"platform:el8-playground" and use module stream expansion (MSE) or
separate branches to build twice, once for each platform. The
buildroot for each of these will be the latest set of tags composed
for the stable repo + default module streams (for el8) and the
playground repo + default module streams (for el8-playground),
respectively, plus whatever module dependencies are needed. Builds
against el8 will be tagged as candidates and must go through
updates-testing. Builds against el8-playground will be tagged directly
into the Modular Playground compose.

Pros: This is closest to what we are doing for regular packages.
Allows us to specialize the builds for dependencies available only in
playground.
Cons: Uses twice the build resources. Requires a compose for the
Modular Playground.


2) We create only one platform module: "platform:el8" using the el8
stable tag plus the Modular stable tag's default streams. We build the
module stream a single time. Builds tagged with
epel8-modular-candidate will be automatically tagged to
epel8-modular-playground. For them to get to epel-testing and later to
epel8-modular-stable, they must be submitted to Bodhi.

Pros: Builds use less resources. Composes for Modular Playground will
be able to hardlink much of their content, so disk space will be
reduced.
Cons: Requires a separate compose for Modular Playground. Cannot
provide specialized builds for deps available only in playground.


3) We create only one platform module: "platform:el8" using the el8
stable tag plus the Modular stable tag's default streams. We build the
module stream a single time. All builds go through Bodhi. Users of
epel8-playground are encouraged to enable the
epel8-modular-updates-testing repo.

Pros: Requires the fewest resources. Needs only the Modular compose.
Cons: Documenting the usage might be confusing. Modular Playground
doesn't get all builds like the epel8-playground does, only the ones
submitted to Bodhi (might impact users who intend to have "build for
playground" as part of their CI/nightly build system).



I have thoughts on which way I am leaning, but I'd prefer to hear a
few external opinions before sharing them. Your input is greatly
desired.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Modularity Policy Discussion for EPEL 8.1

[Stephen Gallagher]

As you know, we delayed support of Modularity in EPEL (called
Application Streams in RHEL) until 8.1 while we worked out some
remaining issues. Some of those issues were technical, but we have a
few others that will come down to policy. In particular, EPEL has to
deal with something Fedora does not: the possibility that it could
come into conflict with streams from the official Red Hat Application
Streams.

I'm going to try to enumerate in this email some of the cases I can
think of that might need attention, as well as providing my
recommendations for what policy we should set in EPEL.

Case 1: EPEL ships a module "foo" with stream "baz" (aka "foo:baz").
This is an alternative stream to RHEL AppStream, which ships
"foo:bar". In a new minor release, RHEL AppStream starts also shipping
"foo:baz".

Case 2: EPEL ships a module "foo:baz". RHEL AppStream does not ship
the module"foo" at all. In a new minor release, RHEL AppStream starts
also shipping "foo:baz".

Case 3: EPEL ships a module "foo:baz". RHEL AppStream does not ship
the module "foo" at all. In a new minor release, RHEL AppStream starts
also shipping "foo:bar".

Case 4: EPEL ships a module "foo:baz". AppStream ships the module
"foo" and has "foo:bar" declared as the default stream.

Case 5: EPEL ships a module "foo:baz". AppStream ships the module
"foo" and has no default stream specified for the "foo" module.

Case 6: EPEL ships a module "foo:baz" that wants to set the default
profile of the "baz" stream to "client". AppStream does not ship the
module "foo".

Case 7: EPEL ships a module "foo:baz" that wants to set the default
profile of the "baz" stream to "client". AppStream ships the module
"foo" and has a default profile set for the "bar" stream.



So lets's break these down. The first three cases are all very
similar. They address the situation where we have both RHEL and EPEL
attempting to own the same name within a namespace (module). My
recommendation here is that we require EPEL module streams to be
prefixed with "epel-". Then, even if RHEL AppStream starts shipping a
stream of the same name, there will be no namespace collision. There
is another benefit as well: it will be easy to tell at a glance
whether a particular stream is from RHEL AppStream (and therefore
supported by Red Hat) or if it comes from EPEL, with only volunteer
community support.

The cases involving default module streams are a bit more complicated.
Making a module stream a "default stream" effectively means that its
contents are treated like the non-modular EPEL 8 contents, except that
installing one of them means that the stream becomes enabled. We need
to figure out, however, whether we should allow EPEL to set default
streams at all. The major issue is that if RHEL later starts shipping
this module and wants to set a default stream, we now have a conflict
to resolve. From a technological standpoint, it can be done: Red Hat
will need to ship the defaults object metadata with a `data.version`
value higher than the one shipped in EPEL. Yum will then prefer that
version over the one in EPEL. A slight risk occurs here if EPEL ships
an update to the defaults data that bumps the version higher again,
but that's really no different than today when someone pushes a
package build to EPEL that ends up in RHEL with a lower version at a
point release.

Things get dicier when we add in the concept of the default profiles,
though. The design of the module defaults metadata did not entirely
take the split repo ownership into account (my fault). So we
essentially have a single YAML document in the metadata that
identifies the default stream and the default profiles for each stream
in the module. Now, there's some leeway here: I did consider the
updates[-testing] use-case, so in the event that two repos both
contain defaults for a module, they can be merged[1] in many cases. If
they have the same `data.version` value, so long as the provided
profiles do not conflict, they will just be merged together. If they
have differing `data.version` values, the higher one will win.


So, I see the following options for how to handle default streams in RHEL 8

Option 1: We disallow assigning default streams at all within EPEL 8.
This will protect us against a future change where RHEL wants to set a
default. Additionally, it means that all EPEL modules are explicitly
opt-in and so we don't ever surprise anyone.

Option 2: We allow making EPEL streams the default stream if RHEL does
not currently provide a default stream. We set strict policy regarding
what a default stream may contain (such as "must not replace any
package provided by RHEL 8"). If RHEL later decides to set a default
for this stream, the RHEL release engineering must ensure that the
`data.version` value is higher than what EPEL 8 carries.

I'm somewhat more in favor of Option 1 here, mostly because it
minimizes the chance of conflicts and ensures the opt-in nature of
EPEL. But I'm willing to hear counter-arguments.



For default 

[EPEL-devel] Re: Rules for shadowing RHEL packages with EPEL modules

[Stephen Gallagher]

On Fri, Aug 23, 2019 at 9:43 AM Petr Pisar  wrote:

> On Fri, Aug 23, 2019 at 08:26:32AM -0400, Stephen John Smoogen wrote:
> > On Fri, 23 Aug 2019 at 06:52, Petr Pisar  wrote:
> > > Case: RHEL delivers a non-modular P package. There is no S stream of
> > > a M module. Can I add a new M module with a new S stream that will
> contain
> > > a modular P package? I guess it will be allowed. Can I make the stream
> > > default? I guess that won't be allowed.
> > >
> >
> > I would agree with your assessment.
> >
> Thank you for the prompt response. I have yet another peculiar corner case
> of
> this one, that I is actually very prominent for me:
>
> We have plenty of Perl packages in RHEL. Most of them are not modularized,
> thus they are compatible only with Perl 5.26, a default perl:5.26 stream.
> I feel there will be a demand for providing their modularized variants in
> EPEL
> so that users can use them even with non-default perl.
>
> All that can be implemented by adding a new module. This is not a problem.
> The
> problem is that the module will an second-class citizen compating to a
> module
> with net new package due to missing the default stream. The reasong for
> banning the default is that the EPEL modular package would mask the
> non-modular RHEL package.
>
> Let's I have a theoretcal way how to build that module so thet a context
> for
> perl:5.26 will be an empty, no RPM package. Then making the stream default
> would not violate the no-replacement rule.
>
> If a user used perl:5.26, yum would install the non-modular package from
> RHEL
> because there won't by any modular package masking it. If a user enabled
> a different perl stream, yum would install the modular package from EPEL.
>
> Would you accept this solution?
>

 I just spent a few minutes trying to figure out if this is technically
possible. I think it *might* be, but the more I think about it, the less I
like it. I think we should approach EPEL with the principle of least
surprise. I don't think any admin should ever get an EPEL package *by
accident*. If they used `yum enable perl:5.24`, I don't think that should
implicitly mean that they start getting EPEL packages. If they want to use
EPEL content, they should have to enable an EPEL stream on purpose.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Rules for shadowing RHEL packages with EPEL modules

[Stephen Gallagher]

On Fri, Aug 23, 2019 at 6:52 AM Petr Pisar  wrote:

> If I read the EPEL 8 annoucement correctly, it's still not possible to
> build
> modules in EPEL. Nevertheless I'd like to know how the rules about "not
> replacing RHEL content" will apply to modules. Here are my question:
>
> Case: RHEL delivers an M module with a default S1 stream. There is no S2
> stream. Can I add a new S2 stream into EPEL? I guess this will be allowed.
> If
> later RHEL introduces S2 stream, I guess EPEL will remove the S2 module.
>
>
As Smooge says downstream, I think EPEL will need to namespace its streams
so it's always clear if you are running an EPEL or RHEL version of a
stream. I also don't think we necessarily need to drop the EPEL version;
since two streams of the same module cannot be enabled at the same time,
there shouldn't be any harm in retaining the EPEL one if there is cause to
do so. (For example, maybe the EPEL version includes experimental features
where the RHEL one has them disabled).


> Case: RHEL delivers an M module with no default stream, there is no S
> stream.
> Can I add a new S stream into EPEL and make it default? I'm not sure this
> will
> be allowed. There is a risk of creating conflicts between streams
> transitively
> required by another default streams. (Remember the libgit2 module conflict
> .)
>
>
I think the only safe approach for EPEL is to disallow the setting of
default streams. This will avoid the possibility of conflicts.



> Case: RHEL delivers a non-modular P package. There is no S stream of
> a M module. Can I add a new M module with a new S stream that will contain
> a modular P package? I guess it will be allowed. Can I make the stream
> default? I guess that won't be allowed.
>


As I said above, I think we probably don't want EPEL to ever ship a default
stream. They should always be supplemental. As for shipping a non-default
stream that carries P: yes, that will work. And it's one of the major
advantages that EPEL gains in RHEL 8: it's finally possible for us to ship
updated versions of RHEL software where required, as long as it is a
conscious user decision. (We need to make it clear that if they enable this
stream, they're not going to be supported for it by Red Hat if it breaks
something else on their system).



>
> Case: RHEL delivers a P package. Can I build a modular P package when
> building
> a new module stream in EPEL only for the purpose of building the module
> and then filter out the P package from the module (i.e. a build-only module
> component) so that the P package does not get into EPEL repository? I guess
> this will be allowed.
>
>
Yes, absolutely. If a package is only needed at build-time, this is an
ideal way to deal with it. We're also going to be improving MBS to make
this simpler: see https://pagure.io/fm-orchestrator/issue/1307 (implementation
of
https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L282
 )



> Could EPEL product owner (or whoever makes and assert the rules) clarify?
> I need to know that to choose the easiest and yet conforming strategy for
> adding new modules into EPEL, especially when dealing with RHEL packages
> unavailable for some module contexts.
>

I hope this helps.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Node.js 6.x in EPEL 7 is effectively EOL today

[Stephen Gallagher]

I am currently building the latest available Node.js 6.17.1 package
for EPEL 7. As it reached EOL upstream, the package in EPEL is likely
to become stale at this point. In the past, we opted at this time to
upgrade to the latest LTS upstream release, however the 6.x line still
has a fairly large deployment base in the wild, so I'm uncomfortable
upgrading it. (Node.js follows semver, so major release versions have
backwards-incompatible changes).

Given the advanced age of RHEL 7, I'm not personally interested in
producing a nodejs8 or nodejs10 package for EPEL (I'll continue
maintaining them as modules for Fedora and, eventually, EPEL 8), but
I'd happily act as a sponsor and advisor to anyone who decides they
want to take this on.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy

[Stephen Gallagher]

On Thu, May 30, 2019 at 4:25 PM James Cassell
 wrote:

> > >
> > > Historical composes are intended to be frozen and unchanging, but this
> > > approach leaves open the possibility of tagging other builds into
> > > epel8-8.Y and regenerating the compose if the need arises. It will
> > > need to be communicated that these repositories will not receive
> > > updates and are intended to be only a snapshot of the past that is
> > > known to work with a particular RHEL 8.Y base.
> >
>
> This will be very helpful, especially if the epel-release .repo file honors 
> the $releasever variable.


Can you explain what behavior you see here? I can't really parse from
your reply what you think/expect to have happen here, and I'd like to
make sure we address it properly.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy

[Stephen Gallagher]

On Thu, May 30, 2019 at 4:02 PM Troy Dawson  wrote:
>
> On Thu, May 30, 2019 at 12:18 PM Kevin Fenzi  wrote:

> > Also might there be people who want to always keep something in rawhide
> > and never push it to the stable stream? Or do we want to encourage only
> > things destined for the next minor change land in epel8-rawhide?
> >
>
> Yes.  We need to keep that in consideration.
> When cleaning up the -testing branches of EPEL6 and EPEL7 we found
> there were people who had versions in -testing that they never
> intended to push to stable.
> Once EPEL8/7 has modularity, there will be an official way to do that,
> but until that happens, we need to assume that some people will use
> rawhide as a way to have a second version of their package.
>

Right, I think Troy has the pulse of it. I think the current design is
compatible with that, though. I see the following common cases from
most to least common:

1) Leave package.cfg in epel8, build only there -> epel8 repo and
epel8-rawhide repo
2) Remove package.cfg in epel 8. Build stable in epel8 -> epel8 repo.
Build major release planned for an upcoming (not necessarily next...)
X.Y release in Rawhide -> epel8-rawhide repo.
3) Remove package.cfg in epel 8. Build stable in epel8 -> epel8 repo.
Build rolling release in epel8-rawhide of the latest upstream bits,
not necessarily ever planning to move it into stable -> epel8-rawhide
repo.

Case 3 I think will slowly disappear once we enable (and simplify
creation of) modules in EPEL 8, since they'll be able to just provide
a non-default stream.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy

[Stephen Gallagher]

On Thu, May 30, 2019 at 3:18 PM Kevin Fenzi  wrote:
>
> > As discussed in the EPEL SIG meeting yesterday, I've written up my
> > thoughts on how to handle epel8 branches.
>
> TLDR: I like it. ;)
>
> > # Considerations
> > * The process must be simple for a Fedora packager to adapt to
> > * It must be possible to stage big (possibly backwards-incompatible) changes
> > * Where possible, the packager experience should be the same as EPEL 7
> >
> > # Proposal
> > There will be two branches created for EPEL 8 in dist-git for each 
> > component:
> >
> > ## epel8:
> > Most packagers will do their work here. This branch will be set up by
> > default with a package.cfg file containing:
> > ```
> > [koji]
> > targets = epel8 epel8-rawhide
> > ```
> > Recent fedpkg supports using package.cfg files in the root of the
> > dist-git repository to trigger builds for multiple releases at the
> > same time.
> >
> >
> > ## epel8-rawhide:
> > This branch will be left alone until and unless the packager decides
> > that they want to stage a major (possibly incompatible) change for the
> > next RHEL 8.Y minor release. At that time, they will need to remove
> > the package.cfg file from the epel8 branch and manually merge the
> > proposed changes desired into the epel8-rawhide branch and build
> > there.
>
> Also might there be people who want to always keep something in rawhide
> and never push it to the stable stream? Or do we want to encourage only
> things destined for the next minor change land in epel8-rawhide?
>
> > The package.cfg setup will mean that running `fedpkg build` in the
> > epel8 branch will cause it to be built both for the
> > epel8-rawhide-candidate and epel8-stable-candidate tags in Koji.
>
> How about we just call the stable tag 'epel8-candidate' ?
>

Sure, that's actually a vestige of my first draft of this, which I
rewrote which had "epel8" as the combined repo and "epel-stable" as
the branched-off one for when you wanted to lock things. After
consideration, I realized that packagers acting like EPEL 7 (generally
only doing the stable, compatible release) would be the common case
and I reversed that to the version you see here. I left the tag names
specific to eliminate ambiguity, but that's entirely a cosmetic choice
and as long as they're unique and consistent, I don't care what they
are, particularly.

> > Packages built for epel8-rawhide-candidate will behave similarly to
> > Rawhide in Fedora and be signed and tagged into an epel8-rawhide
> > compose.
> >
> > Packages built for epel8-stable-candidate will behave similarly to
> > Fedora stable releases and be required to go through Bodhi to get to
> > an epel8 compose (and associated epel8-testing compose).
> >
> > For packages operating in the default configuration, the packager will
> > need to build in the epel8 branch and then submit the built package to
> > Bodhi, just as they would have done for EPEL 7. The side-effect here
> > is that the build will also produce a build that goes to the
> > epel8-rawhide repository without Bodhi intervention.
>
> Or we could at some point hook in gating, just like fedora rawhide.
> Sorry, just had a dream of a pleasant future. ;)
>

I suppose I should have phrased that differently, or just said
"processed in the same manner as Fedora Rawhide". But yes, if we can
get these properly gated, that's also great.

> >
> > When the time comes where an incompatible change needs to land, they
> > must be coordinated to land on an approved schedule. The exact
> > mechanism of scheduling and coordinating this is out of scope for this
> > document and will be decided on by the EPEL Steering Committee.
>
> Yeah, but we should probibly try and figure it out.
>

I was worried that the logistics of this would derail the conversation
about the branching, so I tried to preempt that. The timing is
something that will be a policy, the rest of this proposal is about
technical design.

> I guess there is:
> A. Right after the new minor release comes out
> B. Right after the new minor release comes out for CentOS
> C. Some arbitrary time after the new minor release comes out.
>

No comment at this time :)

> >
> > At this time, the packager must remove the package.cfg file from the
> > epel8 branch and package the new version in the epel8-rawhide branch.
> > With the package.cfg file removed from the epel8 branch, builds in
> > that branch will be built only for the epel8-stable-candidate tag. As
> > before, composes including these builds will be managed by Bodhi
> > updates. Building from the epel8 branch will therefore not be
> > automatically built for epel8-rawhide any longer.
> >
> > Builds intended for the epel8-rawhide repository will need to be built
> > instead from the epel8-rawhide branch, which will build against the
> > epel8-rawhide-candidate target, which will then be signed and pushed
> > to the epel8-rawhide repository like before.
> >
> > Once the package is approved to be promoted from the epel8-rawhide
> > 

[EPEL-devel] Proposal: EPEL 8 Branch Strategy

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As discussed in the EPEL SIG meeting yesterday, I've written up my
thoughts on how to handle epel8 branches.

# Considerations
* The process must be simple for a Fedora packager to adapt to
* It must be possible to stage big (possibly backwards-incompatible) changes
* Where possible, the packager experience should be the same as EPEL 7

# Proposal
There will be two branches created for EPEL 8 in dist-git for each component:

## epel8:
Most packagers will do their work here. This branch will be set up by
default with a package.cfg file containing:
```
[koji]
targets = epel8 epel8-rawhide
```
Recent fedpkg supports using package.cfg files in the root of the
dist-git repository to trigger builds for multiple releases at the
same time.


## epel8-rawhide:
This branch will be left alone until and unless the packager decides
that they want to stage a major (possibly incompatible) change for the
next RHEL 8.Y minor release. At that time, they will need to remove
the package.cfg file from the epel8 branch and manually merge the
proposed changes desired into the epel8-rawhide branch and build
there.


The package.cfg setup will mean that running `fedpkg build` in the
epel8 branch will cause it to be built both for the
epel8-rawhide-candidate and epel8-stable-candidate tags in Koji.

Packages built for epel8-rawhide-candidate will behave similarly to
Rawhide in Fedora and be signed and tagged into an epel8-rawhide
compose.

Packages built for epel8-stable-candidate will behave similarly to
Fedora stable releases and be required to go through Bodhi to get to
an epel8 compose (and associated epel8-testing compose).

For packages operating in the default configuration, the packager will
need to build in the epel8 branch and then submit the built package to
Bodhi, just as they would have done for EPEL 7. The side-effect here
is that the build will also produce a build that goes to the
epel8-rawhide repository without Bodhi intervention.

When the time comes where an incompatible change needs to land, they
must be coordinated to land on an approved schedule. The exact
mechanism of scheduling and coordinating this is out of scope for this
document and will be decided on by the EPEL Steering Committee.

At this time, the packager must remove the package.cfg file from the
epel8 branch and package the new version in the epel8-rawhide branch.
With the package.cfg file removed from the epel8 branch, builds in
that branch will be built only for the epel8-stable-candidate tag. As
before, composes including these builds will be managed by Bodhi
updates. Building from the epel8 branch will therefore not be
automatically built for epel8-rawhide any longer.

Builds intended for the epel8-rawhide repository will need to be built
instead from the epel8-rawhide branch, which will build against the
epel8-rawhide-candidate target, which will then be signed and pushed
to the epel8-rawhide repository like before.

Once the package is approved to be promoted from the epel8-rawhide
compose to the stable compose, the package.cfg should be recreated in
the epel8 branch (this can be automated to make it easier) and a new
build will be made in the epel8 branch that will produce builds in the
epel8-stable-candidate and epel8-rawhide-candidate tags, with the
former then being submitted to Bodhi. This new build must naturally
have a higher ENVR to preserve the upgrade path.

## %dist tag
Packages built against epel8-rawhide-candidate will be built with a
%dist tag of .epel8_rawhide
Packages built against epel8-rawhide-candidate will be built with a
%dist tag of .epel8_Y where “Y” is the latest stable release of RHEL
8.

This dist tag structure ensures that the version of the package in the
stable epel8 repository will win out over the one in the epel8-rawhide
repository if all other aspects of the EVR are the same. (So one would
only pick up a newer version from epel8-rawhide if it was indeed a
higher version number.)

# Historical Composes
Since major changes may occur at RHEL 8.Y releases, we want to support
allowing our users to lock onto a repository that matches that
release. For this, we will generate historical composes, which will
match the stable package set of the prior minor release once the new
minor release comes out.

At 00:00 UTC of the day following a new RHEL 8.Y release, an updated
epel-release package will be pushed, updating the %dist tag to the new
.epel8_Y value. All new builds will thus have the new dist tag. A
script will be run at this time to apply a new Koji tag (epel8-8.Y) to
the latest build of a package with one of the following tags: [
epel8-stable, epel8-stable-pending ]. A compose of the epel8.Y
repository will be created at this time from all packages currently
tagged as epel8-8.Y.

Historical composes are intended to be frozen and unchanging, but this
approach leaves open the possibility of tagging other builds into
epel8-8.Y and regenerating the compose if the 

[EPEL-devel] Re: nodejs broken

[Stephen Gallagher]

On Wed, Aug 23, 2017 at 12:02 PM Peter Robinson 
wrote:

> > The problem is that CentOS 7.4 still doesn't exist yet, so if Node.js
> > requires OpenSSL 1.0.2 functionality, it's still broken for CentOS users.
>
> Yep, but then also is a bunch of other stuff due to the fact things
> were bumped in RHEL, sadly without forking of each el7 dot release
> there's not much can be done about that and the consensus (right or
> wrong) has been to build for RHEL and when CentOS catches up they'll
> be OK.
>
>
Yeah, not having forked minor releases for EPEL tends to leave stuff like
this unsolvable.


> You could do a whole bunch of work here to find CentOS is out before
> the fix hits stable, if you've got that amount of time go for it.
>
>
That was my original plan; to just carry the bundled http-parser in
epel-testing for a week or two while CentOS caught up, then switch the
Bodhi update back to using the unbundled version. Unfortunately, I didn't
foresee the OpenSSL issue.


> > I'm trying right now to figure out if I build it for 1.0.1 functionality
> if
> > 1.0.2 is sufficiently backwards-compatible. Because my initial glance
> > suggests that it might not be and so I would have to choose between
> whether
> > it works against 1.0.1 and breaks RHEL 7.4 users or 1.0.2 and breaks
> CentOS
> > 7.3 users.
> >
>

So, the patch for 1.0.1 support is very invasive and would be painful to
make work when 1.0.2 is in the buildroot (which of course it is because
Koji uses the latest RHEL repos).

I think the only sane approach here is going to be to just drop all of the
7.3-specific stuff and just tell people that they're unfortunately out of
luck on CentOS until 7.4 is out for that platform.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: nodejs broken

[Stephen Gallagher]

On Wed, Aug 23, 2017 at 10:02 AM Peter Robinson 
wrote:

> > It turns out there's an additional issue; it appears that Node.js 6.11.2
> > with the bundled http-parser doesn't work properly with OpenSSL 1.0.1 on
> > EPEL 7. This would also be fixed by requiring RHEL/CentOS 7.4 (since it
> > upgraded to OpenSSL 1.0.2).
> >
> > I'm trying to figure out what to do here. We can't just put back the
> > http-parser in EPEL unfortunately because the RHEL folks unintentionally
> > released a lower NVR for the official package. If we put ours back, it
> would
> > supersede RHEL and take them out of support on any package linking
> against
> > it (which now includes parts of SSSD).
>
> > I'm going to spend a little time today trying to figure out if I can fix
> the
> > OpenSSL 1.0.1 compatibility patch and push out an update that will work
> with
> > the bundled http-parser for now.
>
> Can you not just rebuild nodejs, which will rebuild the bundled
> http-parser, against the new 1.0.2 build in 7.4?
>

The problem is that CentOS 7.4 still doesn't exist yet, so if Node.js
requires OpenSSL 1.0.2 functionality, it's still broken for CentOS users.

I'm trying right now to figure out if I build it for 1.0.1 functionality if
1.0.2 is sufficiently backwards-compatible. Because my initial glance
suggests that it might not be and so I would have to choose between whether
it works against 1.0.1 and breaks RHEL 7.4 users or 1.0.2 and breaks CentOS
7.3 users.

For the record, this is irrespective of the http-parser issue. That one at
least is solved just by carrying the bundled copy for a short time. But I
can't do the same with OpenSSL because the Node.js bundled copy of OpenSSL
is known to have encumbered codecs and I see no value in duplicating the
effort of stripping them out.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: nodejs broken

[Stephen Gallagher]

On Wed, Aug 23, 2017 at 7:17 AM Richard Grainger  wrote:

> OK, thanks,
>
> On Wed, Aug 23, 2017 at 12:13 PM, Anssi Johansson  wrote:
>
>> Anssi Johansson kirjoitti 23.8.2017 klo 13.31:
>>
>>> Richard Grainger kirjoitti 23.8.2017 klo 11.55:
>>>
 yum install nodejs

>>>
>>> Try with this:
>>>
>>> yum install nodejs --enablerepo=epel-testing
>>>
>>> This will install nodejs with http-parser bundled in. http-parser was
>>> removed from EPEL because it is now in RHEL 7.4, and EPEL does not ship
>>> packages that are also in RHEL. http-parser will be in CentOS 7.4 once it
>>> is released.
>>>
>>
>> I forgot to mention that this is only a temporary workaround. Once CentOS
>> 7.4 is released, nodejs will revert back to depending on http-parser from
>> RHEL/CentOS.
>>
>
>

It turns out there's an additional issue; it appears that Node.js 6.11.2
with the bundled http-parser doesn't work properly with OpenSSL 1.0.1 on
EPEL 7. This would also be fixed by requiring RHEL/CentOS 7.4 (since it
upgraded to OpenSSL 1.0.2).

I'm trying to figure out what to do here. We can't just put back the
http-parser in EPEL unfortunately because the RHEL folks unintentionally
released a lower NVR for the official package. If we put ours back, it
would supersede RHEL and take them out of support on any package linking
against it (which now includes parts of SSSD).

I'm going to spend a little time today trying to figure out if I can fix
the OpenSSL 1.0.1 compatibility patch and push out an update that will work
with the bundled http-parser for now.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] EPEL 7 Node.js Uplift

[Stephen Gallagher]

I updated the Bodhi update in EPEL to the latest 6.7.0 security release last
night. I just want to remind people that there remain only three days until EOL
of 0.10.x, so I think we really need to make the cut-over today or tomorrow by
providing karma to push the update to stable. It takes at least a day to make it
to most mirrors.

I wish we had a bit more time for this, but security updates seem to be coming
at an accelerated pace lately. I missed Jim Perrin's original note about a
Fedora Magazine post for EPEL and CentOS to link to (sorry about that, Jim), but
I'll see if I can get something written up and published today. It's probably
"too little, too late", but I'll at least provide the justification.

Part of the reason I support making the cutover immediately is because the
high-severity security updates from last night *also* impact 0.10.x and we don't
have a meaningful way to deliver 0.10.47 to EPEL 7 right now (since the 6.7.0
package is in epel-testing). We either need to cut over to 6.7.0 or else
withdraw that update, push the 0.10.47 update, wait for it to go stable and then
reintroduce 6.7.0. This seems like a large amount of effort for very little 
benefit.

(Apologies for stream-of-consciousness; I'm thinking this through as I type)
I do see one alternative if we want to provide a little more time in testing for
6.x... we could do the above 0.10.47 release by pulling 6.x, *rush* that in by
karma-cheating[*], put 6.7.0 back in updates testing and hold off on the cutover
for X days or the next security release, whichever comes first.

That's fairly convoluted and I'm not personally willing to do the work for it,
but if someone wants to take over I'm game.


[*] Setting karma requirements to 1 and having one of us hand-wave it.



signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Strategy for Node.js upgrade in EPEL 7

[Stephen Gallagher]

Apologies for the re-send, but I typoed the epel-devel email address on the
first try.

On 09/13/2016 09:27 AM, Stephen Gallagher wrote:
> Yesterday, I built the latest upstream version of Node.js for EPEL 7 (this
> version will be supported until 2019-04-01)
> 
> I have added it to the buildroot overrides so that anyone can rebuild their 
> npm
> modules at will. This *is* an API/ABI-breaking upgrade, so some modules will
> fail to function on this version. We don't know ahead of time which ones will 
> do
> so, except for binary modules.
> 
> I am electing *not* to build in a side-tag for this. Many of the noarch 
> packages
> will just work (or they won't, and a rebuild wouldn't help us detect this). I 
> am
> therefore putting out a request to anyone using nodejs-* packages in EPEL to
> please install nodejs from epel-testing[2] and help us find any issues before
> October.
> 
> If you maintain a nodejs-* package in EPEL, please test that it continues to
> work with Node.js 6.x. If it does not, please update it and build it in Koji. 
> If
> the update is compatible with 0.10.x, feel free to submit it to Bodhi; if it 
> is
> not (or you simply want to push them all together), please notify me directly 
> I
> will add it to the Bodhi update for nodejs so that it goes stable at the same
> time as the interpreter.
> 
> 
> 
> Due to upstream terminating support for 0.10.x on 2016-10-01, we *will* be
> cutting over to 6.x on or around that date, so this testing request is
> time-sensitive.
> 
> 
> [1] There's a long story behind this, but the short version is that the 
> bundling
> style of npm makes it basically impossible to maintain, as even bugfix 
> releases
> result in a huge tangled mess of dependencies. It is infeasible to keep up 
> with
> bugfix and security updates. Node.js upstream is highly responsible and
> responsive about security issues, so we considered it an acceptable risk to
> bundle npm with the main package.
> 
> [2] https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/ also has
> it, if your epel-testing mirrors don't have it yet.




signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: nodejs update

[Stephen Gallagher]

On 09/08/2016 01:27 PM, Stephen Gallagher wrote:
> On 08/22/2016 11:23 AM, Stephen Gallagher wrote:
>>
>> OK, as we stated before, we really need to get Node.js 6.x into the
>> updates-testing repository soon. We mentioned that we wanted it to sit there 
>> for
>> at least a month before we cut over, and "at least a month" means "by next 
>> week"
>> since the cut over is planned for 2016-10-01.
>>
>> I'm putting together a COPR right now as a first pass at this upgrade:
>>
>> https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/
>>
>> I've run into the following blocker issues:
>>
>> * We cannot jump to 6.x in EPEL 6 easily at this time, because upstream 
>> strictly
>> requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be 
>> possible
>> to resolve this with SCLs, but I am no expert there. Zuzana?
>>
>> * Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 
>> 1.0.2
>> and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 
>> 6
>> and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution 
>> (SCL
>> or otherwise) for linking EPEL to a newer version of OpenSSL.
>>
>> The OpenSSL 1.0.2 problem is a significant one; we cannot build against the
>> bundled copy of OpenSSL because it includes patented algorithms that are not
>> acceptable for inclusion in Fedora. We also cannot trivially backport 
>> Fedora's
>> OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by 
>> the
>> base RHEL/CentOS repositories.
>>
>>
>> Right now, the only thing I can think of would be for someone to build a
>> parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to 
>> the
>> openssl101e package available for EPEL 5) and patch our specfile to be able 
>> to
>> work with that instead.
>>
>> This is a task I'm not anxious to embark upon personally; there is too much
>> overhead in maintaining a fork of OpenSSL to make me comfortable.
>>
>> How shall we proceed?
>>

Thanks to a lot of help from Haikel Guemar, I now have working builds of Node.js
6.5.0 against EPEL 7. His team was able to write adapt a patch that Solaris
folks wrote to work against OpenSSL 1.0.1. I have put them up in a COPR[1] and
also am running a build in the official EPEL 7 branch which I will get into
updates-testing ASAP.

This *is* a world-breaking change. There have been numerous
backwards-incompatible changes since Node.js 0.10.x, so testing will be 
imperative.

Reminder: Node.js 0.10.x hits EOL on 2016-10-01, so there is no hanging on to
the old version.


[1] https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/



signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: nodejs update

[Stephen Gallagher]

On 08/22/2016 11:23 AM, Stephen Gallagher wrote:
> On 08/11/2016 07:43 AM, Stephen Gallagher wrote:
>> On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote:
>>> Hi!
>>>
>>> As some of you may know, nodejs package that is present in
>>> EPEL is pretty outdated. The current v0.10 that we have will
>>> go EOL in October and npm (package manager) is already not
>>> maintained.
>>>
>>> Currently, upstreams' plan is to have two versions of Long
>>> Term Support (LTS) at once, one in active development and one
>>> in maintenance mode.
>>> Currently active is v4, which is switching to maintenance in
>>> April and v6 which is switching to LTS in October.
>>> This is also reason why we would like to skip v4, although
>>> both will get security updates. Nodejs v6 also comes with
>>> newer npm and v8 (which might best be bundled, as it is in
>>> Fedora and Software Collections) (v8 might concern ruby and
>>> database maintainers, but old v8 package still remains in
>>> the repo).
>>>
>>> There was also an idea to have both LTS versions in repo,
>>> but we're not quite sure, how we'd do it and if it's even a
>>> good idea.
>>>
>>> Also, another thing is, if it is worth of updating every year
>>> to new LTS or update only after the current one goes EOL.
>>> According to guidelines, I'd say it's the latter, but it's
>>> not exactly how node development works and some feedback from
>>> users on this would be nice, because I have none.
>>>
>>>
>>> tl;dr Need to update nodejs, but can't decide if v4 or v6,
>>> v4: will update sooner, shorter support (2018-04-01)
>>> v6: longer support (2019-04-01), *might* break more things,
>>> won't be in stable sooner than mid-October if everything
>>> goes well
>>
>> FYI, I think this tl;dr missed explaining why v6 won't be in stable until
>> mid-October. What Zuzana and I discussed on another list is that the Node.js 
>> v6
>> schedule has it going into LTS mode on the same day that 0.10.x reaches EOL.
>> However, v6 is already out and available. The major thing that changes at 
>> that
>> point is just that from then on, they commit to adding no more major features
>> (as I understand it). This is the best moment for us to switch over to it.
>>
>> However, in the meantime we will probably want to be carrying 6.x in
>> updates-testing for at least a month prior to declaring it stable (with
>> autokarma disabled) with wide announcements about the impending upgrade. This
>> will be safe to do since Node.js 6.x has already reached a point where no
>> backwards-incompatible changes are allowed in, so we can start the migration
>> process early.
>>
> 
> OK, as we stated before, we really need to get Node.js 6.x into the
> updates-testing repository soon. We mentioned that we wanted it to sit there 
> for
> at least a month before we cut over, and "at least a month" means "by next 
> week"
> since the cut over is planned for 2016-10-01.
> 
> I'm putting together a COPR right now as a first pass at this upgrade:
> 
> https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/
> 
> I've run into the following blocker issues:
> 
> * We cannot jump to 6.x in EPEL 6 easily at this time, because upstream 
> strictly
> requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible
> to resolve this with SCLs, but I am no expert there. Zuzana?
> 
> * Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2
> and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6
> and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL
> or otherwise) for linking EPEL to a newer version of OpenSSL.
> 
> The OpenSSL 1.0.2 problem is a significant one; we cannot build against the
> bundled copy of OpenSSL because it includes patented algorithms that are not
> acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's
> OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the
> base RHEL/CentOS repositories.
> 
> 
> Right now, the only thing I can think of would be for someone to build a
> parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to 
> the
> openssl101e package available for EPEL 5) and patch our specfile to be able to
> work with that instead.
> 
> This is a task I'm not anxious to embark upon personally; there is too much
> overhead in maintaining a fork of OpenSSL to make me comfortable.
&g

[EPEL-devel] Re: nodejs update

[Stephen Gallagher]

On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote:
> Hi!
> 
> As some of you may know, nodejs package that is present in
> EPEL is pretty outdated. The current v0.10 that we have will
> go EOL in October and npm (package manager) is already not
> maintained.
> 
> Currently, upstreams' plan is to have two versions of Long
> Term Support (LTS) at once, one in active development and one
> in maintenance mode.
> Currently active is v4, which is switching to maintenance in
> April and v6 which is switching to LTS in October.
> This is also reason why we would like to skip v4, although
> both will get security updates. Nodejs v6 also comes with
> newer npm and v8 (which might best be bundled, as it is in
> Fedora and Software Collections) (v8 might concern ruby and
> database maintainers, but old v8 package still remains in
> the repo).
> 
> There was also an idea to have both LTS versions in repo,
> but we're not quite sure, how we'd do it and if it's even a
> good idea.
> 
> Also, another thing is, if it is worth of updating every year
> to new LTS or update only after the current one goes EOL.
> According to guidelines, I'd say it's the latter, but it's
> not exactly how node development works and some feedback from
> users on this would be nice, because I have none.
> 
> 
> tl;dr Need to update nodejs, but can't decide if v4 or v6,
> v4: will update sooner, shorter support (2018-04-01)
> v6: longer support (2019-04-01), *might* break more things,
> won't be in stable sooner than mid-October if everything
> goes well

FYI, I think this tl;dr missed explaining why v6 won't be in stable until
mid-October. What Zuzana and I discussed on another list is that the Node.js v6
schedule has it going into LTS mode on the same day that 0.10.x reaches EOL.
However, v6 is already out and available. The major thing that changes at that
point is just that from then on, they commit to adding no more major features
(as I understand it). This is the best moment for us to switch over to it.

However, in the meantime we will probably want to be carrying 6.x in
updates-testing for at least a month prior to declaring it stable (with
autokarma disabled) with wide announcements about the impending upgrade. This
will be safe to do since Node.js 6.x has already reached a point where no
backwards-incompatible changes are allowed in, so we can start the migration
process early.


> Also need feedback from users.
> 
> 
> I hope I didn't forget anything important.
> 
> Regards
> 
> Zuzka
> Node.js SIG
> 




signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: EPEL Deprecated Django 1.5 in

[Stephen Gallagher]

On Thu, 2014-10-02 at 12:57 +0300, Dionysis Grigoropoulos wrote:
 On Wed, Oct 01, 2014 at 10:33:07PM +0200, Matthias Runge wrote:
  On Wed, Oct 01, 2014 at 01:28:04PM +0300, Dionysis Grigoropoulos wrote:
   Hello,
   
   as far as I can see, EPEL 7 currently provides packages `python-django`
   and `python-django15` being versions 1.6.5 and 1.5.6 respectively. EPEL
   6 provides `python-django15` and `Django14` being 1.5.6 and 1.4.14.
   
   According to the Django documentation [1], since version 1.7 was
   released, version 1.5 won't receive security updates anymore. Wouldn't
   it be better to remove python-django15 from both repos and add 1.4
   (current LTS which will be supported at least until March of 2015) to
   EPEL 7 and 1.6 to epel 6?
  
  Thank you for the heads-up.
  
  I recently retired python-django15 from Fedora 21+, and I should do the
  same ASAP for EPEL6 and EPEL7 as well.
  
  (THIS IS THE ANNOUNCEMENT ABOUT REMOVAL in about two weeks.)
  
  About adding Django14 to EPEL7: Since there is currently Django-1.6,
  which is supported until March 2015 as well, I don't see any pro to add
  another Django version. The other reason is: having two versions in the
  same release is just a pain; I'd try to avoid this; they need to be
  installable in parallel. We had that, it didn't work very well.
  
  Does this make any sense?
  Matthias
  -- 
  Matthias Runge mru...@matthias-runge.de
 
 Thank you for the quick reply Matthias.
 
 Yes, it makes sense not having two versions of the same software in the
 same release. I've had issues with that myself in the past, notably with
 sqlalchemy in EPEL 6.
 
 My only concern about Django 1.6, is that it's a bit too bleeding edge
 to my taste and a lot of projects on the web still need Django 1.4 due
 to its LTS nature.



It's technically an LTS, but it's still ending support in just a few
months. If we include it in EPEL 7 now, we're effectively committing to
support it a LOT longer than upstream will. I suspect that Matthias
isn't willing to take on that responsibility. However, if you or someone
else wanted to own it, I'm sure Matthias would help you get it off the
ground...


signature.asc
Description: This is a digitally signed message part
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL mock configs for epel7

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/2014 10:40 AM, Miro Hrončok wrote:
 Dne 16.1.2014 16:38, Ken Dreyer napsal(a):
 Would anyone mind sharing their mock configurations for EPEL 7?
 
 I've got this http://ur1.ca/gfot7
 

That's pretty close to
https://bugzilla.redhat.com/show_bug.cgi?id=1041480#c4 which is what
we're using for the COPR epel7 mock config now.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLZKuwACgkQeiVVYja6o6Pu/ACgmb8eB8xBCH2GJwTlt3TEKEQg
P5YAmQEgmBPE/SGouFILzYGx4Ym6ini+
=DHVy
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Django deprecated

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/06/2013 10:21 AM, Matthias Runge wrote:
 Hey, just a heads up
 
 the package Django has been deprecated or EPEL5 and EPEL6. On
 EPEL6, you can use Django14 as well, if you don't require Django
 in version 1.3. Please note, the latter does not receive security
 updates any more and contains at least one known weakness.
 
 For EL5 it's not that simple. Django-1.1 is ways older; I don't
 know, how many known security issues exist. Newer Django versions
 require newer python there.
 

Is there any way we can get usage statistics or a poll of the EPEL 5
users to determine if there is any value in trying to build Django15
atop the python26 stack? I expect this would be quite an undertaking,
given all the dependencies...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlGxybEACgkQeiVVYja6o6PRtwCgqZ+hZdu7J7JcSRLw7e0tIxzi
3LIAn242l2/eyykb+VuWQKTemZ40NcT/
=xmxO
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel