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 approach. regards m.
Later, Robert