Re: How to "enforce" new Python packaging Guidelines (for naming)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 19.4.2017 16:21, Marcin Dulak wrote:


On Wed, Apr 19, 2017 at 4:12 PM, John Dennis <jdennis@xxxxxxxxxx
<mailto:jdennis@xxxxxxxxxx>> wrote:

    On 04/19/2017 05:17 AM, Miro Hrončok wrote:

        Hi,

        Currently, `dnf install python-package` will give you the Python
        2 version. But, as you might know, upstream support for Python 2
        will end in 2020. Around that time (or earlier), we'd like to
        make "python" mean Python 3 in Fedora.
        Before we do that switch, we need to stop using unqualified
        "python" in package names, and instead use either "python2" or
        "python3" everywhere.

        Current packaging guidelines encourage packagers to do the right
        thing (see below for details). But it's not required, and many
        old packages use names that assume "python" means "Python 2".

        What should we do? Should we mass fill bugs asking the packagers
        nicely to follow the new guidelines, or should we make a policy
        about this first and have the mass filled bugs backed up by it?


    Thank you for raising this issue, it's important. Having just
    completed some python packaging work for both Fedora and RHEL I can
    attest the current situation is a bit of a mess. There is
    inconsistency in Fedora over the use of the python-provide macro and
    there can be a fair amount of manual work trying to figure out what
    names should be used for dependencies.

    Compounding the problem is the fact many maintainers have a desire
    to share the spec file between Fedora and RHEL for obvious reasons.
    The situation is far worse in RHEL-7, it's a hodgepodge of different
    names compounded by the lack of the same python macros being used in
    Fedora. Spec files have gotten really ugly and I'm worried about the
    number of "hacks" being added to spec files to compensate (i.e.
    copying macro definitions into the spec file so the same logic can
    be used in RHEL).

    I realize this is a Fedora specific mailing list but we can't simply
    ignore the reality of how packaging is often shared between the two
    distributions.

    After having experienced the pain involved due to the
    inconsistencies (both intra-Fedora and inter-Fedora) my vote would
    be to:

    1) Define the exact rules and migration path.

    2) Coordinate with RHEL.


and EPEL.

    3) File bugs and mandate the rules from #1 be followed and that all
    packages must comply within a well defined period.


This won't be a one step process. Even if one day I follow the
guideline, on my next package update I don't read the guideline and
create a non-compliant package.

4) create scripts which automatically check whether the policy is
followed and open bugs.

Could be added to Taskotron.


Marcin




    --
    John

    _______________________________________________
    packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
    <mailto:packaging@xxxxxxxxxxxxxxxxxxxxxxx>
    To unsubscribe send an email to
    packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
    <mailto:packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx>



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux