Mailinglist Archive: opensuse-packaging (54 mails)

< Previous Next >
Re: [opensuse-packaging] python single-spec progress, questions
  • From: Todd Rme <toddrme2178@xxxxxxxxx>
  • Date: Fri, 28 Oct 2016 08:29:39 -0400
  • Message-id: <CADb7s=tokhZ5-Ufy95ipRQRBV75QKyepVrjLOYe_H-BQPkCiQg@mail.gmail.com>
On Fri, Oct 28, 2016 at 12:22 AM, Simon Lees <sflees@xxxxxxx> wrote:


On 10/28/2016 01:55 PM, Todd Rme wrote:
On Thu, Oct 27, 2016 at 7:35 PM, Simon Lees <sflees@xxxxxxx> wrote:


On 10/28/2016 08:01 AM, Todd Rme wrote:
On Thu, Oct 27, 2016 at 5:07 PM, Simon Lees <sflees@xxxxxxx> wrote:


On 10/28/2016 05:05 AM, Todd Rme wrote:
On Thu, Oct 27, 2016 at 12:51 PM, jan matejek <jmatejek@xxxxxxxx> wrote:
hello packagers,

i'm happy to announce that i have a macroset that works pretty well, if
i say so myself :)
Have a look at the d:l:python:singlespec repository [1] and the github
repo [2] for details.

The gist of it: it is now very possible to build packages for both
python 2 and python 3, using a pretty straightforward set of macros. See
spec files in the linked repository, and documentation on github.

So far this only reliably works on python 2 and 3. It can work with pypy
too, but pypy is not building so I can't test against it.

Some comments on the macros:

1. I think the version number should be explicit in all cases. So it
should be "%have_python2", not "%have_python", and "%have_pypy2" and
"%have_pyp3", not "%have_pypy".
2. Along those lines, I think pypy2 and pyp3 versions should be
available, especially with a lot of progress now happening in pypy3
thanks to mozilla funding it.

4. New policies for d:l:py
---
If the transition goes smoothly, I'd like to use the opportunity to
clean out the devel:languages:python project.

One, d:l:py is collecting applications that happen to be *written in*
Python, but have nothing to do with python development, and should
instead be placed in other topically appropriate projects. We've had
some discussions about dependencies only present in d:l:py, but here's a
policy proposal:

When was this ever not the case? There are packages like that which
haven't been updated in 4 or 5 years. I did some spot checks and the
other devel:languages:___ repos also have a wide variety of software
written in that language. What do you see as wrong with the current
approach?


There is almost always a better repo that they could be in which is less
confusing to users who care about what applications do rather then which
language they live in. For example variety which is a cross desktop
wallpaper fetcher and changer written in python lives in the
X11:Utilites repo because its a Utility for X11 apps, similarly if the
purpose of the application is to monitor servers we have a nice
Server:Monitoring repo I believe.

The problem is that the distinction between "application" and
"library" is not very clear-cut with most python packages. In the
rare case where something is purely an application that happens to be
written in Python, then yes I suppose you are right. But more often
the "application" contains both an executable and a python module that
python scripts can make use of. What should we do in that situation?

For the pure applications, a bunch of those are python shells, python
IDEs, debuggers, or other development tools that are connected in some
way to the python version they were built with and thus need to have
both versions available.

These are probably both valid examples of things that are not libraries
that could stay.

That is almost all, if not all, of the "applications" in d:l:p.

Do you have any specific examples of python-based packages in d:l:p or
d:l:p3 that you think shouldn't be there?

No I personally have not looked I was simply agreeing with the above
quoted statement "One, d:l:py is collecting applications that happen to
be *written in* Python, but have nothing to do with python development"
and agreeing that they should be moved to more appropriate locations

My point is that this tends to be a very blurry line with python. We
need some more specific rules to actually implement this sort of
policy.

As for applications requiring dependencies only in d:l:py the simple
policy should be anything added to d:l:py should also then be forwarded
to openSUSE:Factory where it will hopefully get picked up for the next
Leap release as well. If this is enforced the required deps will always
be available for all repos and it won't be an issue.

Are you talking about all packages or only non-python packages?
Because there are a lot of niche python tools in d:l:p that I don't
think belong in openSUSE:Factory.

All packages, unless they are of no interest to anyone even those doing
python development. Users shouldn't need to add development repo's to
there systems especially ones like d:l:p where there is a high chance
that they can completely break there system by updating with it enabled.
So if its useful to any openSUSE users it should go in the distro if its
not there is probably a question of does it actually need to be there
still? Richard has been pushing this view far more then I but its a view
I agree with (you can watch his openSUSE conference talk).

There are certainly people who hold this view, but I have seen nothing
to suggest it is remotely close to a consensus view. I personally
cannot emphasize how strongly I disagree with this view, and how much
I think it would harm projects like d:l:p. If it becomes official
openSUSE policy, then certainly d:l:p will have to follow it. But I
am strongly opposed d:l:p implementing this policy on its own.
Especially since it would involve eliminating hundreds of useful
packages that our volunteers have been willing to package but aren't
willing to go through the often months-long process of getting
accepted into openSUSE:Factory. We simply don't have the manpower to
get every useful package into openSUSE:Factory, even if they all
belonged there (and I think many of them don't belong there).

While the legal review can take up to a month, although from personal
experience its gotten better of late (Even with the haskell development
project adding 1500 packages at once) It's not like its a month of hard
effort required. If something is packaged reasonably well to start with
and according to openSUSE's guidelines the amount of work required to
get it included is pretty minimal and any issues should be resolved
within 1 or 2 submit requests. If people would like help with this I and
others are willing to spend time helping them fix there issues.
Personally I think that packages in openSUSE development repo's should
be following openSUSE guidelines and packages that are not willing to do
that should be in some other sub repository like d:l:p:Playground but
i'm guessing others would disagree.

I disagree with most of what you said, but this can be discussed
further in the Factory mailing list. What you are suggesting is a
fundamental change to the most basic aspects of how OSC is organized.
I am strongly against using d:l:p as a testing ground for such a
change. Even if I liked the policy, the repo is undergoing too many
other changes right now. We just don't have the manpower to
additionally sift through probably somewhere around 1000 packages,
figure out which one should go into factory, clean them all up, wade
through the submission process, do whatever it is you propose we do
with those that don't make the cut. It is probably going to take
months to just get the scripts implemented, and that process is mostly
automated.

And I don't think there is "a high chance that they can completely
break there system by updating with it enabled", as long as we fix the
issue with the linked libraries that was already brought up.
System-critical python-based packages are not handled in that repo (if
they are they will be moved under the new policy), nor is the
packaging of python itself (that happens in an isolated sub-project).

That still doesn't rule out some users hitting some weird breakages at
times (I've been helping with support on irc for at least 5 years and
have seen some pretty weird breakages due to extra repo's in my time).

That is very different from "a high chance that they can completely
break there system by updating with it enabled".
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation
Follow Ups