Linux's dirty little secret
|
|
|
Comments (48)
28 earlier comments in the full thread.
On GNOME, virtually all apps have a "help" menu item that launches GNOME's help browser with the application's documentation. I'd be surprised in KDE doesn't have something similar.
@Sander: Yes, autopackage seems to be the best bet. It even seems to handle glibc symbol versioning, C++ ABI change, GTK+ version incompatibilities. However, very few third party apps actually seem to be using it?? Maybe the more standard approach is to create LSB complaint packages, but that too seems to be a major task.
Even so, the main issues are that running newer versions of apps is still too hard without upgrading the whole OS, and that the lack of standardization in providing third party apps means that if one is not lucky then one has to compile from source (which can get hairy for GNOME/KDE apps).
Even so, the main issues are that running newer versions of apps is still too hard without upgrading the whole OS, and that the lack of standardization in providing third party apps means that if one is not lucky then one has to compile from source (which can get hairy for GNOME/KDE apps).
@krisum: I see quite a few third party apps use autopackage. But it's likely apps that you've never heared of, like our Dutch IRS's electronic tax return application.
Often, this is not a problem of the package but of the developer. Some developers always rely on the latest features because they have a system that has all that (e.g. a recent Ubuntu or Debian Lenny). Other developers don't use the latest features but don't know about the correct compile flags to make their binary work on older systems. It's really a problem of educating developers on this issue.
Quoting:the main issues are that running newer versions of apps is still too hard without upgrading the whole OS.
Often, this is not a problem of the package but of the developer. Some developers always rely on the latest features because they have a system that has all that (e.g. a recent Ubuntu or Debian Lenny). Other developers don't use the latest features but don't know about the correct compile flags to make their binary work on older systems. It's really a problem of educating developers on this issue.
@Sander: Btw, autopackage still does not handle library incompabilities in other libraries. For example, openssl is libssl.so.0.9.* on some distros while it is libssl.so.4 on redhat/fedora. Linking them statically is not an option since then the libraries in question will not get security and other future fixes.
> Debian uses /usr/share/doc/{application_name} as just such a repository of manuals, "changes", examples, and other useful stuff.
As does Slackware, though it's a symbolic link to /usr/doc. The Linux-FAQs and Linux-HOWTOs are also there.
As does Slackware, though it's a symbolic link to /usr/doc. The Linux-FAQs and Linux-HOWTOs are also there.
@Sander,
Quoting: Other developers don't use the latest features but don't know about the correct compile flags to make their binary work on older systems.For command-line apps that use only C/C++ the compile flags and the neat tricks in autopackage may well work. However, in practise apps have many more dependencies and any recent version of any app that uses GNOME/KDE is unlikely to work since they will have large number of dependencies on newer versions of those libraries. Even if these dependencies are satisfied, compiling something like pidgin from source is quite a big task (i was sent on a wild goose chase of getting sources of its dependencies, and their dependencies etc.).
There are two problems with autopackage that I have found. First, there are technical issues. I don't have time to find links now, but the autopackage devs seemed not to be willing to accept that those problems existed. Second, and much larger, is that the autopackage devs (one in particular) have burned every possible bridge in the FOSS community. My understanding is that the project is no longer very active, though don't quote me on that.
I have posted here before that the rootless Gobolinux install is a good model to follow. Rootless Gobolinux is not ready for prime time, but only because of lack of developer interest. You can install Gobolinux packages inside any other distro. Furthermore, it is trivial to install two versions of the same app/libraries. Installing two OOo versions is difficult on many distros. I installed Gobolinux packages for two different versions of OOo inside of Ubuntu, and they ran flawlessly.
I have posted here before that the rootless Gobolinux install is a good model to follow. Rootless Gobolinux is not ready for prime time, but only because of lack of developer interest. You can install Gobolinux packages inside any other distro. Furthermore, it is trivial to install two versions of the same app/libraries. Installing two OOo versions is difficult on many distros. I installed Gobolinux packages for two different versions of OOo inside of Ubuntu, and they ran flawlessly.
Quoting:> Debian uses /usr/share/doc/{application_name} as just such a repository of manuals, "changes", examples, and other useful stuff.
AFAIK it's just LINUX in general that does this, because it's in the Filesystem Hierarchy Standard:
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITE...
Quoting:This is incorrect. Debian has non-free and contrib repos which serve this purpose.
Great, I'm wrong and the problem is already solved. However, I still can't understand why the first method of installing VMWare on Ubuntu I found on the net was this rather complex one:
https://help.ubuntu.com/community/VMware/Workstation
This is the one I got for Debian:
http://www.howtoforge.com/debian_sarge_vmware_server_howto
This lead me to believe installing VMWare in Debian takes more than the two steps it takes in Gentoo (apart from the license issue). So my question: Where's the two step guide to installing VMWare in Ubuntu?
Quoting:Anyway, is somebody aware of a kind of 'Distro-tour' (like the tour in XP) that is available in any distro...
Yes, Linspire, everyone's favorite whipping boy has one. (Had one?)
Well, honestly, they deserve kudos for that. At least in my opinion. Every distro which (partially) aims at the computer illiterates should provide one.
Quoting:Rootless Gobolinux is not ready for prime time, but only because of lack of developer interest. You can install Gobolinux packages inside any other distro. Furthermore, it is trivial to install two versions of the same app/libraries
I'd say: Superseded by Klik(2) these days,
http://en.wikipedia.org/wiki/Klik_(packaging)
which offers the same features and more. In fact it's (also?) a protocol which tools like Konqueror can recognize (like media:/ ). And the best thing is, because 1 app is one file it's trivial to delete apps. It was mainly designed to be able to provide cross-distro packages which you can mail to your grandma even if she uses another distro, and she can just 'klik' on it and it starts. It also uses 'partially writable filesystem overlays' instead of symbolic links. However, not many people are aware of this opportunuty and it's not installed by default in distro's, neither are there 'klik' packages available for each distro.
@hkwint
http://www.ubuntugeek.com/how-to-install-vmware-server-from-... https://help.ubuntu.com/community/VMware/Server
As i mentioned it is more work in hardy than in gutsy since for some reason the deb was removed from the partner repository. In debian lenny/sid it is as simple as installing vmware-package available in contrib repos.
Even if these were not available, the point being made was that third-party apps not available in the official repos (with vmware being just an example) are harder to install on linux -- same holds if an ebuild is not available for third-party apps (e.g. one of the many at freshmeat/sourceforge/kde-apps etc.)
Quoting: This lead me to believe installing VMWare in Debian takes more than the two steps it takes in Gentoo. So my question: Where's the two step guide to installing VMWare in Ubuntu?The guide you saw is for the commercial VMware workstation. Here are the ones for vmware server:
http://www.ubuntugeek.com/how-to-install-vmware-server-from-... https://help.ubuntu.com/community/VMware/Server
As i mentioned it is more work in hardy than in gutsy since for some reason the deb was removed from the partner repository. In debian lenny/sid it is as simple as installing vmware-package available in contrib repos.
Even if these were not available, the point being made was that third-party apps not available in the official repos (with vmware being just an example) are harder to install on linux -- same holds if an ebuild is not available for third-party apps (e.g. one of the many at freshmeat/sourceforge/kde-apps etc.)
Quoting:I'd say: Superseded by Klik(2) these days,
Klik has it's disadvantages as well. There was a big discussion about Klik a few months back on these forums. It's okay for the occasional application I guess, but I prefer regular packages.
The thing about package management is that Free software will always work much better with it than non-free software. For a FOSS developer it's extremely easy. Just build a source .tar.gz using any of the major build systems (autotools, scons, etcetera) and distro packagers world-wide will do the rest for you. Not so for non-free Linux software.
Quoting: ust build a source .tar.gz using any of the major build systems (autotools, scons, etcetera) and distro packagers world-wide will do the rest for you.I do not see this happening for a huge number of (useful) projects in freshmeat/kde-apps/sourceforge/...
Quoting:but I prefer regular packages.
OK, but they're not cross-distro. I wish packages were; it would be handy if for example the treasury could spread its tax application in one simple-to-install format. I remember our treasure (Belastingdienst) complained about only very few people using the Linux tax program to fill out and submit their tax return, but now I have used it I understand why; it's not a program my grandma could start (well, neither is filling out tax forms something she and most other grandma's can, but you get the idea). Maybe Autopackage or ZeroInstall is the solution, I don't know, but at this moment the package management fragmentation is a big problem. Both for the tax service and companies like VMWare and Google.
Quoting:and distro packagers world-wide will do the rest for you.
True, but and if those nice persons go on holiday or have an argument and strike you have a problem. Also, they duplicate their work dozens of times for each distro. Most of it is a waste of time. For example, in Klik (the only cross-platform package manager I 'understand') you can take a .deb file and make a Klik receipe. Than, Red Hat, Gentoo, Mandriva, OpenSuse and PCLinuxOS users can use it with a single click. That means, Red Hat, Gentoo, Mandriva, OpenSuse and PCLinuxOS package maintainers are jobless and can do something more useful than duplicating work others have done already (it goes also for .rpm's by the way). Imagine how much time could be saved to do useful things!
Quoting:Just build a source .tar.gz using any of the major build systems
If you make a Klik recipe after that, which is rather straight forward, you can put the Klik link on your site and testers don't have to wait for the distro packagers. Much more people could test (since Klik enables to install multiple versions) much faster. Also, if people can report problems directly to the developer instead of to their distro team. It's far easier for the developer, since he doesn't have to wonder about if it's a distro packaging problem or a bug he created. So it's a better way of bug fixing as well.
Indeed package managers take care of everything, but they present a unnecessary layer of complexity / waiting which is prone to errors. Totally needless in my opinion and a waste of time. Those people should concentrate on making a simple uniform way of installing apps, and that way has to work with Skype, Picasa, VMWare, AdobePhotoshop trial under Wine (something you can distribute using Klik) and Free Software. Of course, it's easier for packagers if people only use Free Software. But people just ask for Skype, Photoshop etc., and if Linux doesn't provide it, they simply won't use it.
A correction:
Our Dutch tax return application already uses autopackage. Even my computer illiterate mother managed to install & run it.
Quoting:it would be handy if for example the treasury could spread its tax application in one simple-to-install format. I remember our treasure (Belastingdienst) complained about only very few people using the Linux tax program to fill out and submit their tax return ... Maybe Autopackage or ZeroInstall is the solution
Our Dutch tax return application already uses autopackage. Even my computer illiterate mother managed to install & run it.
Aside from that, I disagree that packaging is just duplicate work. Packagers do integration within their specific distro as well. And as a first line of bug fixers they can often fix things much faster than upstream can. Plus, it gives a Linux user a central place to file bugs.
Without distro-specific packages there wouldn't be distro's. There would be just one "Linux" like there is one "Windows". Linux's strength is it's diversity, and it's the packagers that make this happen.
Packaging has more benefits (like educating new devs) , but these are the most important IMHO.
Without distro-specific packages there wouldn't be distro's. There would be just one "Linux" like there is one "Windows". Linux's strength is it's diversity, and it's the packagers that make this happen.
Packaging has more benefits (like educating new devs) , but these are the most important IMHO.
It almost seems we need a universal package format that is able to be linked to the distro's package management/tweaking setup.
Yeah, I know this would most likely require source archives to work properly.
I guess the idea would be, package X is setup in a universal package, but distro Z needs to add patches 1, 2, and 3 to it and use a tweaked init script, and their management system knows that and behaves accordingly.
Which brings us back to source archives I guess...which kinda defeats the purpose of universal packages...(unless the packages include both the default binaries and the source for if the distro needs to tweak it).
Iunno...sounds complicated to me...
A more interesting challenge and perhaps a bigger challenge would be to convince all the developers before hand that there is a proper specific place for software be installed to in the first place. Gentoo has a different set up than Ubuntu than Mandriva. All land their software in different locations. And while it is a simple matter to adjust $PATH a single install to rule them all and in the darkness bind them, well that needs to get more than just a package management system in place.
> Without distro-specific packages there wouldn't be distro's. There would be just one "Linux" like there is one "Windows".
Distro-specific packages are better, provided they are available. However, not all packages are available for all distros. Most distros have too few devs to package everything (not even Debian has everything).
What is needed is a universal package format that can be installed on any distro. That is why I will go back to the rootless Gobolinux install I've mentioned multiple times (the concept, not necessarily this specific implementation). All that is required is that you have a home directory and you can install Gobolinux packages in your distro of choice. You can install multiple versions of apps/libraries with no problems.
Then every free software project could make the latest version available in that package format. Distros could still provide their own packages if they choose to do so.
Distro-specific packages are better, provided they are available. However, not all packages are available for all distros. Most distros have too few devs to package everything (not even Debian has everything).
What is needed is a universal package format that can be installed on any distro. That is why I will go back to the rootless Gobolinux install I've mentioned multiple times (the concept, not necessarily this specific implementation). All that is required is that you have a home directory and you can install Gobolinux packages in your distro of choice. You can install multiple versions of apps/libraries with no problems.
Then every free software project could make the latest version available in that package format. Distros could still provide their own packages if they choose to do so.
@hkwint
Quoting: If you make a Klik recipe after that, which is rather straight forward, you can put the Klik link on your site and testers don't have to wait for the distro packagers.So does Klik handle backward compatibility issues of libc6 etc. (e.g. if building on recent distro can the binaries made to work on older distro)? What about updates to the application? Also since it seems to package all dependencies, is it able to load installed GTK themes etc.
Quoting:guess the idea would be, package X is setup in a universal package, but distro Z needs to add patches 1, 2, and 3 to it and use a tweaked init script, and their management system knows that and behaves accordingly. Which brings us back to source archives I guess...
You don't go back to the source archives actually. If it were in the source archives, it would be in upstream. And it's not. IMHO what this leads to is centralized, cross-distro patch management. And IIRC some folk are already working on this: a central place where all the packagers of all the distro's can come and store, exchange, share and improve on patches for all FOSS applications.
The next step would be to create an application that can automatically build distro-native packages from an upstream source tarball and a set of patches from this central repository.
Quoting:So does Klik handle backward compatibility issues of libc6 etc. (e.g. if building on recent distro can the binaries made to work on older distro)?
Depends on what you compile it against. The idea is, you compile it against an 'as old as possible' lib, and then you hope the new lib is backwards compatible. No guarantee of course, but in the practice it works rather well.
Quoting:What about updates to the application?
You have to make a new recipe, just like with current package managers.
Quoting:Also since it seems to package all dependencies
Not all of them, it assumes a 'standard base'. It packs only dependencies which are possibly not found on a desktop distro, like Mono. I believe it assumes your distro comes with most Gnome / KDE libraries, glibc, etc. In practice, more than 90% of the time the 'Proof of concept' (Klik v1) worked; so it's not perfect of course. But it does install apps in the home directory, and it doesn't need root-privileges to (de)install software since it ends up in a single file in the users home directory anyway. That's great, as it doesn't require a password either and every user can have his own packages and versions of it.
Quoting:The next step would be to create an application that can automatically build distro-native packages from an upstream source tarball and a set of patches from this central repository.
As far as I understood, that's exactly what Fabio did with Entropy. Check out Sabayon 3.5 and coming.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
