On Friday, 25 August 2017 13:17:47 CEST Greg Freemyer wrote:
On Fri, Aug 25, 2017 at 9:42 AM, Prof. Dr.-Ing. Franz-Joseph Barthold
<franz-joseph.barthold@tu-dortmund.de> wrote:
Dear maintainers,
I recently installed openSUSE Leap 42.3 on a laptop and customized the software development infrastructure on both laptop and on a HPC server. I observed some outdated packages and other minor inconsistencies. The current versions are mentioned in braces.
In general, as far as I would recommend it, a recent software stack should be available without relying on some home: repo.
1. make (4.2.1) 4.0-7.15 on openSUSE-Leap-42.3-Oss (version 5 years old) There is one recent version (4.2.1) available at home:Ledest
The same for bison (2.7-11.15 vs. 3.0.4-0.45)
2. doxygen (1.8.13) doxygen and doxywizad (1.8.11) are distributed. In devel:tools, doxygen is current (1.8.13), but the accompanying doxywizard is only (1.8.11). Thus, this particular tool chain is broken.
http://download.opensuse.org/distribution/leap/42.3/repo/oss/suse/x86_64/? P=doxy* shows consistent versions for the released state of openSUSE Leap 42.3 . The development project shows the current state of what a development project is for: Development :-) What I can see in https://build.opensuse.org/package/show/devel:tools/doxygen is that openSUSE Tumbleweed shows a consistent set of packages for both doxygen and doxywizard in version 1.8.13. For openSUSE Leap 42.3 the build is "disabled". Why this is so is not obvious to me but you could contact the maintainers of that project, see https://build.opensuse.org/package/users/devel:tools/doxygen
3. midnight commander (4.8.19) Distribution (4.1.15), but only in home:Ximi1970 the current version (4.19)
openSUSE Leap 42.3 should have 4.8.15, I assume you mistyped.
Don't forget you can add the devel repos for those packages and get the latest from there.
I think that is great solution for me.
I use a solid (or even old) base of software in Leap 42.3.
Then I personally layer on the security:forensics repo and get recent versions of those packages from there.
I also do not see the problem nor a better possibility. Picking a version is about compromises. I currently run openSUSE Leap 42.2 and also use it for software development. For some specific cases I add custom repositories which is way better than trying to mangle manually with RPM files or even building these packages locally myself but this also means I am running what you can call a custom distribution because probably no one else has exactly the same repository configuration as I have it. openSUSE Tumbleweed would provide many more up-to-date versions but also comes with a need to keep adapting with more and bigger updates. The only viable alternative I see is to take any version of openSUSE Tumbleweed that works with the versions at that time, not update it but also not have it connected to the Internet (no updates == unsafe). If you see that certain packages are only available in a certain home project then this is a good resemblance of how the current level of support is. Basically it means that there is at best a single person caring about that package. devel-projects commonly are maintained by multiple persons so response time on requests is usually also quicker then. In the case of the development tools you mentioned it however only means that there was seen no strong need for for a major update. The major versions of the tools you mention in most cases come from the latest SUSE Linux Enterprise release. The lifecycle of these products are described on http://suse.com/lifecycle/ The base for openSUSE Leap 42.3 is SUSE Linux Enterprise 12 SP3 with the base version SUSE Linux Enterprise 12 being released on 27 Oct 2014. Since then important bugfixes and security fixes are applied to the packages including the ones you mentioned. Only in rare cases the major versions are updated. Customers of SUSE Linux Enterprise of the option to active a so called "Module", e.g. for a more recent toolchain. For the free openSUSE releases you have the possibility to add more recent versions from OBS projects - and I agree with you, that should not need to be home repos - but of course without the support that a SLE customer would get. -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-programming+owner@opensuse.org