Mailinglist Archive: opensuse-packaging (54 mails)

< Previous Next >
[opensuse-packaging] Re: python single-spec progress, questions
On 29.10.2016 11:57, Robert Schweikert wrote:
Making the package names explicit with respect to the version would get
people used to a disassociation of the command line name and the
associated packages. Today, with the Python-2 interpreter being the
default one uses "python" on the command line and installs modules with
binary packages called "python-foo". Thus there is a nice match in
names. However, at some point in the future the "python" command will
start the Python-3 interpreter and then all of a sudden one has to
install "python3-foo" to use the module. So my thought is, if we break
this association now, while Python-2 is still the default, then the
change when Python-3 becomes the default is not going to be as traumatic
as people will already be used to not having the "python" command and
the binary package names be associated by name.

At this point it seems realistic to aim to switch the default python to
Python 3 in SLE 13. For that, we would need to rename "python" to
"python2", and keep "python" just as a provided symbol. This might also
be an opportunity to move to "python2-foo" + "python3-foo" and make
"python-foo" just a provided symbol too.

This way the association is never broken.

(Please note that at this point there is no concrete plan for the
switch. It's just what seems realistic to me personally.)

I agree I don't think we should start to evict packages from d:l:p based
on some nebulous arbitrary policy decision. If an application is written
in Python it should be able to live in d:l:p. Chances are the
application provides some modules that are useful for other purposes and
the maintenance burden is reduced on the maintainer.

OTOH, if you want to add a repository for, say, all geodesics packages,
you shouldn't need to add Application:Geo ... AND d:l:py and d:l:ruby
and d:l:haskell and d:l:javascript and d:l:intercal, just because some
of your geodesics apps happen to be written in a particular language.

Also, adding the package to, say, Application:Geo, the maintenance
burden is moved from d:l:py maintainers to App:Geo maintainers. This
even makes more sense in that App:Geo maintainers probably care more
about keeping a "core" package up to date, as opposed to d:l:py
maintainers for whom a random app is not considered core.

The "provided modules" thing is also nebulous. For me, a good rule of
thumb is this: if the application does not have an API documentation (or
if the API is merely a way to invoke the utility without using system()
), it is probably not useful as a library.
And conversely, if there *is* an extensive and documented API, it's
probably a good Python library that happens to have an app bundled, and
I am happy about having it in d:l:py ;)

If we evict the
application from d:l:p and make it live in d:myapp then the maintainer
of myapp has a good chance of having to back link a rather large number

That's why these packages should be submitted to Factory in the first place.

of packages from d:l:p in addition to having to deal with prjconfig,
repo setup etc. which are things that are currently handled by the d:l:p
project maintainers.

which also should not be necessary in general. If it is, the solution
should be to make sure you can build a package anywhere without hassle,
not to collect it in a project that did the work.

Of course, the latter solution is more practical.
But while we're talking about big changes, I'm aiming for the clean



< Previous Next >
List Navigation