4:51 a.m.
Hi all,
as you probably know, the "Python 3 as a Default" [1] change has been accepted
by FESCo and is currently targeted for F22.
As a part of that Change, I also wrote that we should rethink some aspects of Python
packaging in Fedora. I have put together a proposal that summarizes the current state and
proposes a new approach to Python packaging [2]
Before I propose it to FPC, I'd like to discuss it and work on it here on lists and
incorporate everybody's notes/suggestions.
So thanks for reading this through and sending your comments.
Slavek.
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://fedoraproject.org/wiki/Changes/Python_3_as_Default
[2] https://fedoraproject.org/wiki/User:Bkabrda/Py2to3GuidelineChanges
5:14 a.m.
On 12/04/2013 11:51 AM, Bohuslav Kabrda wrote:
Hi all,
as you probably know, the "Python 3 as a Default" [1] change has been accepted
by FESCo and is currently targeted for F22.
As a part of that Change, I also wrote that we should rethink some aspects of Python
packaging in Fedora. I have put together a proposal that summarizes the current state and
proposes a new approach to Python packaging [2]
Before I propose it to FPC, I'd like to discuss it and work on it here on lists and
incorporate everybody's notes/suggestions.
So thanks for reading this through and sending your comments.
You are missing that "Provides" in your examples.
And I would emphasize
http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_E...
and even put in to your guidelines example. Because a lot of maintainers forgot this.
Something like:
Be sure to correctly (replace
package)[http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FRe....
# first version where binary python2-foo replaced python-foo
%global old_version 1.23
%package -n python2-foo
...
Provides: python-foo = %{version}-%{release}
Obsoletes: python-foo < %{old_version}
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
5:23 a.m.
What about package that doesn't have python- prefix?
I saw that in the example:
%if 0%{?with_python2}
...
BuildRequires: tkinter
%endif
%if 0%{?with_python3}
...
BuildRequires: python3-tkinter
%endif
So I guess tkinter is Python 2. Should it be renamed to python2-tkinter
and provide tkinter? Or should Python 3 version provide tkinter? Or both?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5:35 a.m.
----- Original Message -----
On 12/04/2013 11:51 AM, Bohuslav Kabrda wrote:
> Hi all,
> as you probably know, the "Python 3 as a Default" [1] change has been
> accepted by FESCo and is currently targeted for F22.
> As a part of that Change, I also wrote that we should rethink some aspects
> of Python packaging in Fedora. I have put together a proposal that
> summarizes the current state and proposes a new approach to Python
> packaging [2]
> Before I propose it to FPC, I'd like to discuss it and work on it here on
> lists and incorporate everybody's notes/suggestions.
> So thanks for reading this through and sending your comments.
You are missing that "Provides" in your examples.
I didn't put them there intentionally, since I think it would be best if RPM created
these automatically.
And I would emphasize
http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_E...
and even put in to your guidelines example. Because a lot of maintainers
forgot this.
Something like:
Be sure to correctly (replace
package)[http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FRe....
# first version where binary python2-foo replaced python-foo
%global old_version 1.23
%package -n python2-foo
...
Provides: python-foo = %{version}-%{release}
Obsoletes: python-foo < %{old_version}
As noted above, the Provides should IMO be generated by RPM. I'm however quite sure
that this is not an option for Obsoletes... Maybe we would need to add the obsoletes for
one or two releases manually and then remove them...
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
--
Regards,
Bohuslav "Slavek" Kabrda.
5:37 a.m.
----- Original Message -----
What about package that doesn't have python- prefix?
I saw that in the example:
%if 0%{?with_python2}
...
BuildRequires: tkinter
%endif
%if 0%{?with_python3}
...
BuildRequires: python3-tkinter
%endif
So I guess tkinter is Python 2. Should it be renamed to python2-tkinter
and provide tkinter? Or should Python 3 version provide tkinter? Or both?
(tkinter is actually a subpackage of python itself) Renaming tkinter to python2-tkinter
(with proper Provides and Obsoletes) would be the way to go here, I think. I'll fix it
in the proposal.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
Regards,
Bohuslav "Slavek" Kabrda.
5:47 a.m.
Dne 4.12.2013 12:37, Bohuslav Kabrda napsal(a):
(tkinter is actually a subpackage of python itself)
I guess you know what I mean here, but to be clear:
tkinter is only an example, we got more, like pyserial, PyYAML...
Other thing:
What about apps? Do we want something in the guidelines that would say:
If the app clearly works with both Python 2 and Python 3,
then the Fedora package is obligated to use Python 3 instead
of Python 2.
If however the app only works with one of them, obviously,
Fedora package uses and requires that one.
Or do we keep that on the packager's decision?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:18 a.m.
----- Original Message -----
Dne 4.12.2013 12:37, Bohuslav Kabrda napsal(a):
> (tkinter is actually a subpackage of python itself)
I guess you know what I mean here, but to be clear:
tkinter is only an example, we got more, like pyserial, PyYAML...
Oh, I see. Some time ago, FPC has accepted a change that says, that packages with
"py" in name should be prefixed with "python-" anyway [1]. Since this
only applies to newly created packages, we will have to cope with this, unfortunately. So
my idea of handling this would be:
- all packages must have Provides: python-*
- packages that weren't prefixed with "python-" previously (pyserial,
PyYAML), should also carry an explicit Provides/Obsoletes for the old name.
Sounds good?
Other thing:
What about apps? Do we want something in the guidelines that would say:
If the app clearly works with both Python 2 and Python 3,
then the Fedora package is obligated to use Python 3 instead
of Python 2.
If however the app only works with one of them, obviously,
Fedora package uses and requires that one.
Or do we keep that on the packager's decision?
Toshio already proposed a guidelines solution for this [2], but now that I look at it, it
seems that it never got proposed to FPC. Toshio, will you propose that or should I? I
guess we can do this regardless of the change I'm proposing now.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://fedorahosted.org/fpc/ticket/271
[2] https://lists.fedoraproject.org/pipermail/python-devel/2013-November/0005...
6:34 a.m.
On Wed, Dec 4, 2013 at 1:18 PM, Bohuslav Kabrda <bkabrda(a)redhat.com> wrote:
----- Original Message -----
> Dne 4.12.2013 12:37, Bohuslav Kabrda napsal(a):
> > (tkinter is actually a subpackage of python itself)
>
> I guess you know what I mean here, but to be clear:
>
> tkinter is only an example, we got more, like pyserial, PyYAML...
Oh, I see. Some time ago, FPC has accepted a change that says, that
packages with "py" in name should be prefixed with "python-" anyway
[1].
Since this only applies to newly created packages, we will have to cope
with this, unfortunately. So my idea of handling this would be:
- all packages must have Provides: python-*
- packages that weren't prefixed with "python-" previously (pyserial,
PyYAML), should also carry an explicit Provides/Obsoletes for the old name.
Sounds good?
> Other thing:
>
> What about apps? Do we want something in the guidelines that would say:
>
> If the app clearly works with both Python 2 and Python 3,
> then the Fedora package is obligated to use Python 3 instead
> of Python 2.
>
> If however the app only works with one of them, obviously,
> Fedora package uses and requires that one.
>
> Or do we keep that on the packager's decision?
Toshio already proposed a guidelines solution for this [2], but now that I
look at it, it seems that it never got proposed to FPC. Toshio, will you
propose that or should I? I guess we can do this regardless of the change
I'm proposing now.
How about using "python" in that case? "python-*" should use
the correct
python version, whichever is enabled in the current Fedora release, so
nothing should change for such programs.
Take whaawmp [3] as an example and let's assume it works on python2 and
python3 out of the box. There is "python" everywhere, so when there is the
switch from "python pointing to python2" to "python pointing to
python3"
(and similar for all python macros of course), a simple rebuild should be
sufficient. Isn't it?
Greetings,
Tom
[1] https://fedorahosted.org/fpc/ticket/271
[2]
https://lists.fedoraproject.org/pipermail/python-devel/2013-November/0005...
[3] http://pkgs.fedoraproject.org/cgit/whaawmp.git/tree/whaawmp.spec
6:36 a.m.
On Wed, Dec 4, 2013 at 1:18 PM, Bohuslav Kabrda <bkabrda(a)redhat.com> wrote:
----- Original Message -----
> Dne 4.12.2013 12:37, Bohuslav Kabrda napsal(a):
> > (tkinter is actually a subpackage of python itself)
>
> I guess you know what I mean here, but to be clear:
>
> tkinter is only an example, we got more, like pyserial, PyYAML...
Oh, I see. Some time ago, FPC has accepted a change that says, that packages with
"py" in name should be prefixed with "python-" anyway [1]. Since this
only applies to newly created packages, we will have to cope with this, unfortunately. So
my idea of handling this would be:
- all packages must have Provides: python-*
- packages that weren't prefixed with "python-" previously (pyserial,
PyYAML), should also carry an explicit Provides/Obsoletes for the old name.
Sounds good?
What about packages named without the python- prefix for consistency [1]
with other distros ?
Which rule should prevail ?
Dridi
[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming
> Other thing:
>
> What about apps? Do we want something in the guidelines that would say:
>
> If the app clearly works with both Python 2 and Python 3,
> then the Fedora package is obligated to use Python 3 instead
> of Python 2.
>
> If however the app only works with one of them, obviously,
> Fedora package uses and requires that one.
>
> Or do we keep that on the packager's decision?
Toshio already proposed a guidelines solution for this [2], but now that I look at it, it
seems that it never got proposed to FPC. Toshio, will you propose that or should I? I
guess we can do this regardless of the change I'm proposing now.
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://fedorahosted.org/fpc/ticket/271
[2] https://lists.fedoraproject.org/pipermail/python-devel/2013-November/0005...
--
packaging mailing list
packaging(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
2:22 p.m.
On Wed, Dec 04, 2013 at 06:35:28AM -0500, Bohuslav Kabrda wrote:
----- Original Message -----
> On 12/04/2013 11:51 AM, Bohuslav Kabrda wrote:
> > Hi all,
> > as you probably know, the "Python 3 as a Default" [1] change has
been
> > accepted by FESCo and is currently targeted for F22.
> > As a part of that Change, I also wrote that we should rethink some aspects
> > of Python packaging in Fedora. I have put together a proposal that
> > summarizes the current state and proposes a new approach to Python
> > packaging [2]
> > Before I propose it to FPC, I'd like to discuss it and work on it here on
> > lists and incorporate everybody's notes/suggestions.
> > So thanks for reading this through and sending your comments.
>
> You are missing that "Provides" in your examples.
I didn't put them there intentionally, since I think it would be best if RPM created
these automatically.
Put them in. These sorts of deps that will end up in manual deps and will
be used by the user's to install packages should be explicit. deps that are
both provided and required via autodeps only are okay to be implicit.
-Toshio
3:40 p.m.
On Wed, Dec 04, 2013 at 07:18:31AM -0500, Bohuslav Kabrda wrote:
----- Original Message -----
> Dne 4.12.2013 12:37, Bohuslav Kabrda napsal(a):
> > (tkinter is actually a subpackage of python itself)
>
> I guess you know what I mean here, but to be clear:
>
> tkinter is only an example, we got more, like pyserial, PyYAML...
Oh, I see. Some time ago, FPC has accepted a change that says, that packages with
"py" in name should be prefixed with "python-" anyway [1]. Since this
only applies to newly created packages, we will have to cope with this, unfortunately. So
my idea of handling this would be:
- all packages must have Provides: python-*
- packages that weren't prefixed with "python-" previously (pyserial,
PyYAML), should also carry an explicit Provides/Obsoletes for the old name.
Sounds good?
I would remove that first bullet point. The point of the Provides and
Obsoletes is to provide backwards compatibility. If there's no previous
python-* there's no need to take up that name in the namespace.
> Other thing:
>
> What about apps? Do we want something in the guidelines that would say:
>
> If the app clearly works with both Python 2 and Python 3,
> then the Fedora package is obligated to use Python 3 instead
> of Python 2.
>
> If however the app only works with one of them, obviously,
> Fedora package uses and requires that one.
>
> Or do we keep that on the packager's decision?
Toshio already proposed a guidelines solution for this [2], but now that
I look at it, it seems that it never got proposed to FPC. Toshio, will you
propose that or should I? I guess we can do this regardless of the change
I'm proposing now.
[2] https://lists.fedoraproject.org/pipermail/python-devel/2013-November/0005...
Please do. I haven't got a whole lot of time these days :-(
-Toshio
3:45 p.m.
On Wed, Dec 04, 2013 at 01:34:14PM +0100, Thomas Spura wrote:
On Wed, Dec 4, 2013 at 1:18 PM, Bohuslav Kabrda
<bkabrda(a)redhat.com> wrote:
----- Original Message -----
> Dne 4.12.2013 12:37, Bohuslav Kabrda napsal(a):
> > (tkinter is actually a subpackage of python itself)
>
> I guess you know what I mean here, but to be clear:
>
> tkinter is only an example, we got more, like pyserial, PyYAML...
Oh, I see. Some time ago, FPC has accepted a change that says, that
packages with "py" in name should be prefixed with "python-"
anyway [1].
Since this only applies to newly created packages, we will have to cope
with this, unfortunately. So my idea of handling this would be:
- all packages must have Provides: python-*
- packages that weren't prefixed with "python-" previously (pyserial,
PyYAML), should also carry an explicit Provides/Obsoletes for the old name.
Sounds good?
> Other thing:
>
> What about apps? Do we want something in the guidelines that would say:
>
> If the app clearly works with both Python 2 and Python 3,
> then the Fedora package is obligated to use Python 3 instead
> of Python 2.
>
> If however the app only works with one of them, obviously,
> Fedora package uses and requires that one.
>
> Or do we keep that on the packager's decision?
Toshio already proposed a guidelines solution for this [2], but now that I
look at it, it seems that it never got proposed to FPC. Toshio, will you
propose that or should I? I guess we can do this regardless of the change
I'm proposing now.
How about using "python" in that case? "python-*" should use the
correct python
version, whichever is enabled in the current Fedora release, so nothing should
change for such programs.
Take whaawmp [3] as an example and let's assume it works on python2 and python3
out of the box. There is "python" everywhere, so when there is the switch from
"python pointing to python2" to "python pointing to python3" (and
similar for
all python macros of course), a simple rebuild should be sufficient. Isn't it?
Timeframewise, we're most likely going to want to switch programs over to
/usr/bin/python3 before we switch /usr/bin/python over to point at
/usr/bin/python3. So it would be best to keep these separate. Also, if
"/usr/bin/python" gets injected into programs, there's a moderate to high
chance that they'll fail (many applications are still python2 vs python3
selectable at build time rather than at runtime).
-Toshio
3:54 p.m.
On Wed, Dec 04, 2013 at 01:36:53PM +0100, Dridi Boukelmoune wrote:
On Wed, Dec 4, 2013 at 1:18 PM, Bohuslav Kabrda
<bkabrda(a)redhat.com> wrote:
> ----- Original Message -----
>> Dne 4.12.2013 12:37, Bohuslav Kabrda napsal(a):
>> > (tkinter is actually a subpackage of python itself)
>>
>> I guess you know what I mean here, but to be clear:
>>
>> tkinter is only an example, we got more, like pyserial, PyYAML...
>
> Oh, I see. Some time ago, FPC has accepted a change that says, that packages with
"py" in name should be prefixed with "python-" anyway [1]. Since this
only applies to newly created packages, we will have to cope with this, unfortunately. So
my idea of handling this would be:
> - all packages must have Provides: python-*
> - packages that weren't prefixed with "python-" previously (pyserial,
PyYAML), should also carry an explicit Provides/Obsoletes for the old name.
> Sounds good?
What about packages named without the python- prefix for consistency [1]
with other distros ?
Which rule should prevail ?
Dridi
[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming
The python- naming guidelines take precedence as they are more specific to
the situation than the general naming guideline.
-Toshio
4:10 a.m.
----- Original Message -----
On Wed, Dec 04, 2013 at 07:18:31AM -0500, Bohuslav Kabrda wrote:
> ----- Original Message -----
> Oh, I see. Some time ago, FPC has accepted a change that says, that
> packages with "py" in name should be prefixed with "python-"
anyway [1].
> Since this only applies to newly created packages, we will have to cope
> with this, unfortunately. So my idea of handling this would be:
> - all packages must have Provides: python-*
> - packages that weren't prefixed with "python-" previously (pyserial,
> PyYAML), should also carry an explicit Provides/Obsoletes for the old
> name.
> Sounds good?
>
I would remove that first bullet point. The point of the Provides and
Obsoletes is to provide backwards compatibility. If there's no previous
python-* there's no need to take up that name in the namespace.
Ok, I updated the wiki page with some more talk about the Provides and Obsoletes, which
should incorporate this change and also the others mentioned. You can check out just the
diff [1]
> > What about apps? Do we want something in the guidelines
that would say:
> Toshio already proposed a guidelines solution for this [2], but now that
> I look at it, it seems that it never got proposed to FPC. Toshio, will you
> propose that or should I? I guess we can do this regardless of the change
> I'm proposing now.
>
> [2]
> https://lists.fedoraproject.org/pipermail/python-devel/2013-November/0005...
>
Please do. I haven't got a whole lot of time these days :-(
Done [2].
-Toshio
Thanks,
Slavek.
[1]
https://fedoraproject.org/w/index.php?title=User%3ABkabrda%2FPy2to3Guidel...
[2] https://fedorahosted.org/fpc/ticket/373
8:54 a.m.
On Wed, Dec 4, 2013 at 10:45 PM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Wed, Dec 04, 2013 at 01:34:14PM +0100, Thomas Spura wrote:
> On Wed, Dec 4, 2013 at 1:18 PM, Bohuslav Kabrda <bkabrda(a)redhat.com>
wrote:
>
> ----- Original Message -----
> > Dne 4.12.2013 12:37, Bohuslav Kabrda napsal(a):
> > > (tkinter is actually a subpackage of python itself)
> >
> > I guess you know what I mean here, but to be clear:
> >
> > tkinter is only an example, we got more, like pyserial, PyYAML...
>
> Oh, I see. Some time ago, FPC has accepted a change that says, that
> packages with "py" in name should be prefixed with "python-"
anyway
[1].
> Since this only applies to newly created packages, we will have to
cope
> with this, unfortunately. So my idea of handling this would be:
> - all packages must have Provides: python-*
> - packages that weren't prefixed with "python-" previously
(pyserial,
> PyYAML), should also carry an explicit Provides/Obsoletes for the
old name.
> Sounds good?
>
> > Other thing:
> >
> > What about apps? Do we want something in the guidelines that would
say:
> >
> > If the app clearly works with both Python 2 and Python 3,
> > then the Fedora package is obligated to use Python 3 instead
> > of Python 2.
> >
> > If however the app only works with one of them, obviously,
> > Fedora package uses and requires that one.
> >
> > Or do we keep that on the packager's decision?
>
> Toshio already proposed a guidelines solution for this [2], but now
that I
> look at it, it seems that it never got proposed to FPC. Toshio, will
you
> propose that or should I? I guess we can do this regardless of the
change
> I'm proposing now.
>
>
>
> How about using "python" in that case? "python-*" should use the
correct
python
> version, whichever is enabled in the current Fedora release, so nothing
should
> change for such programs.
>
> Take whaawmp [3] as an example and let's assume it works on python2 and
python3
> out of the box. There is "python" everywhere, so when there is the
switch from
> "python pointing to python2" to "python pointing to python3"
(and
similar for
> all python macros of course), a simple rebuild should be sufficient.
Isn't it?
>
Timeframewise, we're most likely going to want to switch programs over to
/usr/bin/python3 before we switch /usr/bin/python over to point at
/usr/bin/python3. So it would be best to keep these separate. Also, if
"/usr/bin/python" gets injected into programs, there's a moderate to high
chance that they'll fail (many applications are still python2 vs python3
selectable at build time rather than at runtime).
That was my point. When /usr/bin/python is switched to point to
/usr/bin/python3, then %{python_sitearch} also needs a switch to
%{python3_sitearch} (and all other macros too) and the application can see
at build time which python is around and build/work with that.
If a package maintainer wants to switch to python3 earlier, then (s)he can
do so, but this use case from above would be automatic this way.
Greetings,
Tom
3788
days inactive
3789
days old
packaging@lists.fedoraproject.org
14 comments
6 participants
participants (6)
-
Bohuslav Kabrda -
Dridi Boukelmoune -
Miro Hrončok -
Miroslav Suchý -
Thomas Spura -
Toshio Kuratomi