Idea
#6117: LTS should get the newest versions of standard programs
|
| |
45
|
|
|
Written by bart the 30 Mar 08 at 19:48.
Category: Accessibility.
Related to:
Nothing/Others.
Status: New
|
|
|
Description
If you install an LTS version, you may chose to stay with it until the next LTS version. Problem is that you will stay with old programs and will not have access to the newest versions of The Gimp, OpenOffice, ...
People running LTS versions should be able to go and install OpenOffice when it comes out via the Ubuntu repo's and not via getdeb.net or via the official OpenOffice site.
Example: Hardy ships with The Gimp 2.4.5 and it will stay 2.4.5, when 2.5.0 is launched and we want to have it we need to go to getdeb or the Gimp site and download it. Same when OpenOffice 3.0 comes out.
This option should be made possible via the update manager.
This function is not necessary for people running other versions because these have a short lifespan and programs will not change a lot in 6-12 months.
Tags:
(none)
Attachments
No attachments.
Duplicates
Comments
|
neon wrote on the 30 Mar 08 at 19:57
|
gimp 2.5 is the development branch. ;P 2.6 is what you were looking for.
and I believe this is what backports are for. ^_^
|
|
doan wrote on the 30 Mar 08 at 20:01
| |
Backports :p
|
|
bart wrote on the 30 Mar 08 at 21:46
| |
Backports are not supported by Ubnutu. It should be made a lot easier.
|
|
maix wrote on the 30 Mar 08 at 21:49
| |
If you want the latest versions of programs, why do you use a LTS version then?
|
|
johan wrote on the 31 Mar 08 at 02:34
| |
LTS-releases should not be provided with the newest applications. Security-updates only. "Well tested" is the mantra I believe.
|
|
bart wrote on the 31 Mar 08 at 06:25
|
Maybe I'm not clear enough. I'm not talking about the newest versions like every new release, I'm talking about major releases.
Like The Gimp which is 2.4.5. Skip all versions until 2.5 (or 2.6 like neon said). Take that major release and ship it with the repo's, supported by Ubuntu, not like the backports, this is not supported.
|
|
flip314 wrote on the 31 Mar 08 at 06:27
|
Clearly you don't understand the concept of LTS. If you absolutely NEED to be on the bleeding edge, upgrade every 6 months.
There's often very good reasons why stuff isn't backported. You can end up pulling in new versions of libraries that break/require upgrade of other software.
LTS = stable = very few changes.
6 month release = bleeding edge = most recent apps
|
|
derick.eisenhardt wrote on the 31 Mar 08 at 15:09
| |
The core of the problem here is that Ubuntu/Canonical see all the applications as part of the distribution/OS. The core components of the operating system, system utilities, libraries, etc.. should be separated from all the applications. Then they can have LTS releases for the OS, but continue to release new versions of the apps. But this will probably never happen unfortunately...
|
|
livio wrote on the 31 Mar 08 at 15:58
|
All the software that comes with Ubuntu must be supported by Canonical. If this software are Solid as Rock, there's no need for calling the support, avoiding losing productivity.
If you want the latest software, you can download it from the oficial website. For exemple, Opera provides packages for various versions of Ubuntu, so there's no need for Opera Browser to stay in Ubuntu repos.
|
|
flip314 wrote on the 1 Apr 08 at 14:15
|
@derick: The problem is that you can't separate applications from the OS core because of something called libraries.
Scenario:
v0.9 of application foo requires libxyz version >= 1.2, so Hardy ships with libxyz v1.2.
v1.0 of application foo requires libxyz version >= 1.6
libxyz 1.6 cannot be backported because it breaks applications bar and baz which require libxyz v1.0-v1.4
So now you have an LTS version of the OS, but you can't install the flashy new version of the application you want. You can try to patch the application to use the old libraries, but that isn't always possible, because there's probably a reason they needed the new libraries in the first place.
The same thing happens on windows (see "DLL hell"), windows just won't stop you from doing it.
|
|
derick.eisenhardt wrote on the 1 Apr 08 at 19:36
|
@flip: The libraries would be part of the OS portion, and the apps would simply have to be compiled to match what comes with the distro. If it came down to a programmatic problem, I'm sure with Ubuntu's marketshare developers would make sure their apps were compatible with the standard Ubuntu libraries. Furthermore, if an app needs a library or different version than the ones included, there's always the option of including that library with the package in subdirectory of the program or statically compiling it in. It's not impossible.
Also, this wouldn't be a problem if Debian/Ubuntu were to use a more flexible filesystem hierarchy like that of Gobo Linux, then you could have any version of the library you need installed at the same time without conflict.
|
|
flip314 wrote on the 2 Apr 08 at 06:24
|
@derick: Just playing devil's advocate here, but any apps that already work with existing libraries are likely to be backported eventually anyway.
Static compiling is usually a bad option because 1) it makes apps hard to maintain/release security fixes for because you have to maintain the library as well as the app 2) it defeats the whole purpose of a shared library, which is to have code that can be reused.
Multiple versions can be a problem too because 1) having too many versions can defeat the purpose of shared libraries by needing multiple copies in memory 2) maintainers have to release security fixes/patch multiple versions of libraries (might not be a HUGE problem if all versions are maintained upstream or as part of LTS) 3) apps may match more than one compatible version of the libraries. do you a) pick arbitrarily, b) use whichever one is already in memory, c) have some systematic method or what?
In either way, you're defeating the purpose of LTS which is to be stable. If your applications and libraries keep updating, you're more likely to have bugs introduced into the system, which is what you probably wanted to avoid in the first place by choosing LTS.
I'm not saying it's impossible, I'm just saying that you might not want what you think you want.
|
|
gmatht wrote on the 10 Apr 08 at 16:05
| |
Potentially, you could have the backported applications and libraries all sitting in /usr/backports so that they do not interfere with the stable versions.
|
Post your comment
|
|
|
