Hi Jason,
On Tue, Jul 05, 2016 at 03:19:30PM -0400, Jason Newton wrote:
Hi Tomáš,
As you were overloaded last week, I just wanted to poke you again and make sure you know that LEAP is out in the cold here.
Thanks. What are your expectations on that? Could you please describe how the solution you would like to see should look like?
Also, regarding libatlas3, it is missing in openSUSE:Factory - I didn't see the other 2 repos coming into play. Since it looks like it was there and last updated a year ago, I think it got silently cut?
I'd rather not speculate.
Which means the projects linking to them (d:l:p:python3) need to remove it's references or resurrect the package, no?
Exactly.
S_W
I guess I missed something or d:l:p:Factory now has LEAP on the repo list - too much time between replies for me to remember. But still towards the original point, I think d:l:p:Factory packages should be linked into python3's project so we have a single stable repo for this topic. Further, rather than python3 it should be d:l:p:latest, or stable. The point is latest stable python distribution but actually stable (and self contained) as a repository too. If this is disagreeable, then at least rename/re-purpose d:l:p:Factory to be something more stable sounding.
For libatlas3 - your replies seemed to me to be proding me to take some action... I thought ML was action for this but none the less, I submitted a libatlas3 deletion request to d:l:python3 on OBS.
-Jason
On Fri, Jul 8, 2016 at 8:25 AM, Tomáš Čech sleep_walker@opensuse.org wrote:
Hi Jason,
On Tue, Jul 05, 2016 at 03:19:30PM -0400, Jason Newton wrote:
Hi Tomáš,
As you were overloaded last week, I just wanted to poke you again and make sure you know that LEAP is out in the cold here.
Thanks. What are your expectations on that? Could you please describe how the solution you would like to see should look like?
Also, regarding libatlas3, it is missing in openSUSE:Factory - I didn't see the other 2 repos coming into play. Since it looks like it was there and last updated a year ago, I think it got silently cut?
I'd rather not speculate.
Which means the projects linking to them (d:l:p:python3) need to remove it's references or resurrect the package, no?
Exactly.
S_W
On Fri, Jul 8, 2016 at 10:14 AM, Jason Newton nevion@gmail.com wrote:
I guess I missed something or d:l:p:Factory now has LEAP on the repo list - too much time between replies for me to remember. But still towards the original point, I think d:l:p:Factory packages should be linked into python3's project so we have a single stable repo for this topic. Further, rather than python3 it should be d:l:p:latest, or stable. The point is latest stable python distribution but actually stable (and self contained) as a repository too. If this is disagreeable, then at least rename/re-purpose d:l:p:Factory to be something more stable sounding.
d:l:p:Factory is not necessarily stable. Well, the Python version is, but Python 3 updates often break existing Python packages. Python 3.5.2, for example, is apparently incompatible with python3-qt5, and will be for some time. So if you install d:l:p:Factory there is a very good chance you will end up with broken packages. And that is only for "patch" level updates, minor version update (3.x) are larger still.
Also, KDE and Python 3 are very different things. KDE is a set of libraries and applications built on those libraries. As long as you recompile those applications, it is not that big a deal. Python, on the other hand, is a programming language, and a lot of packages outside of d:l:p3 provide interfaces in that language. For example rpm provides python 3 bindings. If you update from python 3.4 to 3.5 all those packages will break, because they depend on a particular python minor version (so python 3.4 or 3.5). So that would imply update really low-level components like rpm, in which case you might as well be using Tumbleweed, or recompiling these packages for every supported openSUSE version in d:l:p3, which would be a huge maintenance burden especially since they could break on patch-level Python release. Further, this burden would be pushed on to any project that build any python3 package of any sort for LEAP, since if every project doesn't do it then we will end up with a mix of incompatible python packages.
So this is simply infeasible in practice. The whole point of differentiating stable release distros from rolling release one is that it is infeasible to make large changes to low-level components in a stable release distro. If you really need updated versions of low-level components like core programming languages, you should either use a rolling release distro or a stand-alone distribution of that language like Anaconda.
I hadn't considered Anaconda for Linux - I do run it on Windows... I guess that makes some sense although I get the feeling this is also going to run into some problematic separations between the distro and core OS. I often find Qt5 is not supported for many packages there, for instance.
I get your point about python being wedged into a difficult to upgrade standalone spot - it is frustrating to have this problem on both Python and LLVM/clang - I'm sure there's a few more things like this lying around. I think a few of the ones that really matter could be linked in from the other up to date repos for some of the simpler cases, but that does make me raise my eyebrow a little. Obviously bringing KDE into the mix makes things even worse unless we make subproject overlays to support this kind of fanning out. If the projects are well coordinated, that works and maybe technical the best solution, in moderation. Famous last words but it is unacceptable that you must run tumbleweed to have an up to date python (or clang for that matter) - I like rolling release, but only in small parts, as a concept for day to day development.
Given preference between my experiences with anaconda's tools/releases and OBS based - I choose OBS. Further, the split between self contained vs integrated with the distribution will run into issues with shared library version and runtime linking issues - I've been down that road before.
-Jason
On Fri, Jul 8, 2016 at 10:41 AM, Todd Rme toddrme2178@gmail.com wrote:
On Fri, Jul 8, 2016 at 10:14 AM, Jason Newton nevion@gmail.com wrote:
I guess I missed something or d:l:p:Factory now has LEAP on the repo list - too much time between replies for me to remember. But still towards the original point, I think d:l:p:Factory packages should be linked into python3's project so we have a single stable repo for this topic. Further, rather than python3 it should be d:l:p:latest, or stable. The point is latest stable python distribution but actually stable (and self contained) as a repository too. If this is disagreeable, then at least rename/re-purpose d:l:p:Factory to be something more stable sounding.
d:l:p:Factory is not necessarily stable. Well, the Python version is, but Python 3 updates often break existing Python packages. Python 3.5.2, for example, is apparently incompatible with python3-qt5, and will be for some time. So if you install d:l:p:Factory there is a very good chance you will end up with broken packages. And that is only for "patch" level updates, minor version update (3.x) are larger still.
Also, KDE and Python 3 are very different things. KDE is a set of libraries and applications built on those libraries. As long as you recompile those applications, it is not that big a deal. Python, on the other hand, is a programming language, and a lot of packages outside of d:l:p3 provide interfaces in that language. For example rpm provides python 3 bindings. If you update from python 3.4 to 3.5 all those packages will break, because they depend on a particular python minor version (so python 3.4 or 3.5). So that would imply update really low-level components like rpm, in which case you might as well be using Tumbleweed, or recompiling these packages for every supported openSUSE version in d:l:p3, which would be a huge maintenance burden especially since they could break on patch-level Python release. Further, this burden would be pushed on to any project that build any python3 package of any sort for LEAP, since if every project doesn't do it then we will end up with a mix of incompatible python packages.
So this is simply infeasible in practice. The whole point of differentiating stable release distros from rolling release one is that it is infeasible to make large changes to low-level components in a stable release distro. If you really need updated versions of low-level components like core programming languages, you should either use a rolling release distro or a stand-alone distribution of that language like Anaconda. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 8, 2016 at 12:29 PM, Jason Newton nevion@gmail.com wrote:
I hadn't considered Anaconda for Linux - I do run it on Windows... I guess that makes some sense although I get the feeling this is also going to run into some problematic separations between the distro and core OS. I often find Qt5 is not supported for many packages there, for instance.
Then use a tumbleweed virtual machine just for your python development.
I get your point about python being wedged into a difficult to upgrade standalone spot - it is frustrating to have this problem on both Python and LLVM/clang - I'm sure there's a few more things like this lying around. I think a few of the ones that really matter could be linked in from the other up to date repos for some of the simpler cases, but that does make me raise my eyebrow a little. Obviously bringing KDE into the mix makes things even worse unless we make subproject overlays to support this kind of fanning out. If the projects are well coordinated, that works and maybe technical the best solution, in moderation.
The problem is that this can't be done in moderation, it is an all-or-nothing thing. Either every package everywhere does it, or none do it. Because if only some packages do it then it will a nightmare of incompatible packages. And if we start doing it with other packages, like LLVM/clang, then the number of possible combinations of package versions quickly becomes enormous. 4 packages, each with only two versions, is 16 possible combinations. That is tripling the number of build targets d:l:p3 currently has. Rebuilding all the Python 3 packages can already take a day or two, our build system is not prepared to handle that many duplicates of so many packages.
Famous last words but it is unacceptable that you must run tumbleweed to have an up to date python (or clang for that matter) -
Even if the practical issues were fixed, it is a matter of available time. There are only a few active Python package maintainers. We are having a hard time just keeping up with normal Python 3 packages and openSUSE version idiosyncrasies. Python 2 packages have already fallen behind due to the lack of time. Having to handle multiple entire Python stacks per distro is simply out of the question, even if it was feasible from a technical standpoint. We need several more people to step up just to properly handle the system we already have, I can't even imagine how many people it would take to do what you are proposing.
I like rolling release, but only in small parts, as a concept for day to day development.
The point with core packages like languages, compilers, etc. is that it is almost impossible to safely do rolling releases "only in small parts". Everything has to be built and tested together. Pieces built with one version of a package have a good chance of breaking if built with another. So you need to either update everything together (as in a rolling release), or stick to a known working combination (as in a stable release).
Given preference between my experiences with anaconda's tools/releases and OBS based - I choose OBS. Further, the split between self contained vs integrated with the distribution will run into issues with shared library version and runtime linking issues - I've been down that road before.
Anaconda has a much, much, much smaller group of supported packages and paid full-time developers managing them. So it is much easier for them to maintain multiple parallel python versions.
On Fri, Jul 8, 2016 at 10:41 AM, Todd Rme toddrme2178@gmail.com wrote:
On Fri, Jul 8, 2016 at 10:14 AM, Jason Newton nevion@gmail.com wrote:
I guess I missed something or d:l:p:Factory now has LEAP on the repo list - too much time between replies for me to remember. But still towards the original point, I think d:l:p:Factory packages should be linked into python3's project so we have a single stable repo for this topic. Further, rather than python3 it should be d:l:p:latest, or stable. The point is latest stable python distribution but actually stable (and self contained) as a repository too. If this is disagreeable, then at least rename/re-purpose d:l:p:Factory to be something more stable sounding.
d:l:p:Factory is not necessarily stable. Well, the Python version is, but Python 3 updates often break existing Python packages. Python 3.5.2, for example, is apparently incompatible with python3-qt5, and will be for some time. So if you install d:l:p:Factory there is a very good chance you will end up with broken packages. And that is only for "patch" level updates, minor version update (3.x) are larger still.
Also, KDE and Python 3 are very different things. KDE is a set of libraries and applications built on those libraries. As long as you recompile those applications, it is not that big a deal. Python, on the other hand, is a programming language, and a lot of packages outside of d:l:p3 provide interfaces in that language. For example rpm provides python 3 bindings. If you update from python 3.4 to 3.5 all those packages will break, because they depend on a particular python minor version (so python 3.4 or 3.5). So that would imply update really low-level components like rpm, in which case you might as well be using Tumbleweed, or recompiling these packages for every supported openSUSE version in d:l:p3, which would be a huge maintenance burden especially since they could break on patch-level Python release. Further, this burden would be pushed on to any project that build any python3 package of any sort for LEAP, since if every project doesn't do it then we will end up with a mix of incompatible python packages.
So this is simply infeasible in practice. The whole point of differentiating stable release distros from rolling release one is that it is infeasible to make large changes to low-level components in a stable release distro. If you really need updated versions of low-level components like core programming languages, you should either use a rolling release distro or a stand-alone distribution of that language like Anaconda. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-
Jason Newton -
Todd Rme -
Tomáš Čech