On Tue, Aug 27, 2019 at 10:20 AM Miroslav Suchý wrote:
> 2) Mock now supports subscription-manager, which allows you to build
> packages for RHEL with cost-free developer license.
> No need to wait for CentOS 8.
>
Does this work when using Fedora as the base system? subscription-manager
is
On Tue, Sep 13, 2016 at 2:28 PM, Stephen John Smoogen
wrote:
>
> The reasoning for needing a python3-foobaz is that we don't replace
> the python2 version of foobaz with a package which does not work at
> all with the python2 installed and possibly breaks an existing app.
>
I'm looking for some clarification on the naming requirements for SRPMs.
In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names
can't conflict with RHEL SRPM names, but in the Limited Arch Packages
[2]section of EPEL: Packaging, it seems to imply the SRPM name would be the
same,
On Wed, Aug 24, 2016 at 8:44 PM, Jason L Tibbitts III
wrote:
>
> To be completely fair, I don't actually know EPEL policy here. The rule
> is that you can't conflict with RHEL packages, but SRPMs aren't really
> installed the same way as other packages and whether or not they
>
> Which is an annoying bit of process, but it would be quite possible to
> exempt those packages from needing package reviews. It needn't take
> that long.
>
>
Not needing reviews would help, but I wonder how hard it would be to make
them children of python-PACKAGE. The main issue is the SRPM
Definitely, but it runs into the same problem as 3.4 on EL7, the fact that
there are few packages available and adding them when the package already
exists in RHEL requires creating a separate parent package in Fedora pkgdb.
On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawski
So what should package maintainers do? I modified a package to use
python3_pkgversion and it builds fine if with_python3 is set, but it
doesn't seem to be set in the EPEL 7 build environment. I noticed a couple
packages enable it by default. Is that what we should be doing? Or should
we just build