Third-party software installation for any Linux distribution

[deanjo]

Did they get it set up on their own, completely, no help or guidance?

Hey they made it through installing linux on their own which requires more effort then installing nwn.

[elanthis]

Hey they made it through installing linux on their own which requires more effort then installing nwn.

That almost qualifies them as uber-nerds then.

[Thetargos]

@elanthis

I wasn't offering a counter point, rather saying that things could be much simpler and use existing infrastructure, no need to "reinvent the wheel" or "recreate the black thread", and that at some point it kinda looks as if you are over convoluting things.


The "installer" the way I see it, should not "live in the repos", rather inside the distro, be intrinsic to the distro with a common interface for the local package management infrastructure, and "self installable pacakges" could be analogous as the ODF files (simply specially crafted .zip files with a distinct extenstion) in that the internal heriarchy and the XML descriptors define the type of file and what it does (and what makes an ods, odp, odt file a spreadsheet, presentation or text file, respectively).

I wouldn't advise starting using those as general packages, though; make it strictly for third party software that wouldn't otherwise deal with native package management policies/hierarchies/licenses/etc.

[elanthis]

@elanthis

I wasn't offering a counter point, rather saying that things could be much simpler and use existing infrastructure

Well, the problem is, there isn't an infrastructure. There's RPM, DPKG, yum, apt, and the other native package tools. That's it. There is no magical PackageKit infrastructure like you are implying.

PackageKit does not replace or enhance the native package system. It's just a veneer over it. Literally, it's just a library and a GUI that abstracts "yum install" and "apt-get install" to "pkcon install", combined with some policies about to make finding dependencies a bit easier. PackageKit knows absolutely nothing about how to unpack packages, resolve dependencies, download updates, or anything. All it does is call out to a yum or apt backend to do all the actual work. PackageKit is entirely and utterly incapable of installing any software that is not already packaged in the system's native package format and likewise incapable of updating any software not in the distro's native repository format.

So there has to be a new format defined, or you have to use one of the existing formats and use something like alien to get them into the native package databases. This is the path LSB tried to take by mandating RPM 3.x as the official package format; unfortunately, they left too much of the rest of the process completely unspecified. Plus RPMs and the like don't support licenses/EULAs which while distasteful are mandatory for most third-party publishers (heck, even a lot of Open Source/Free Software installers use them!).

Given the limitations of the existing formats, I feel it is best to create a new one. I have in the past proposed updates to both dpkg and rpm for more application-oriented installers and they have been roundly rejected because the developers think their locked-down package silos are a Freedom-saving feature rather than a user-hostile design flaw.

The "installer" the way I see it, should not "live in the repos", rather inside the distro, be intrinsic to the distro with a common interface for the local package management infrastructure

Which means the installer is a package in the distribution's package repository. All software in the distribution comes from its package repository, including (for example) rpm, PackageKit, yum, and so on. So the installer must be a part of the distribution's repository.

What I meant is the same thing you meant: the installer has to be a part of the distribution's native package set that the distribution ships and supports, not something the user must manually install by himself.

It doesn't have to be installed by default. The MIME/extension lookup feature Nautilus/Konquerer/Firefox implement via PackageKit means that the native packaging system can install the installer package on demand the first time the user clicks on an installer file. This is important, because I can guarantee you that the installer will not be in the default install set, because distros like Fedora have very strict policies and a lot of politics involved in deciding what goes into that default install set. Luckily, it doesn't matter. So long as the installer is in Fedora's repository, it'll Just Work if the user ever needs it. Magic!

I wouldn't advise starting using those as general packages, though; make it strictly for third party software that wouldn't otherwise deal with native package management policies/hierarchies/licenses/etc.

I have no intention of replacing the core package infrastructure of a distribution. I'm not sure that even makes sense: the way you manage a _platform_ and the way you manage an _application_ are fundamentally different. You can build a single system that does both, but said system will be highly complex. RPM and DPKG for instance are massively complex beasts, and still have a crappy user-experience for handling applications. Fedora/RedHat for instance relies on a whole separate database (comps) for logically grouping the plethora of packages that make up a single application into a user-friendly bundle... and the user still ends up being exposed to a ton of firefox-foobazbigglerarr package names in various bits of the graphics UI.

The way I've specified things is tightly tailored for actual applications (things that run in the GUI, get a menu entry, and of which the user is intended to be acutely aware of), based on how actual application-oriented installers for both Windows and Linux have worked for many years. It looks big and complicated only because it's so different than how RPM and DPKG and such work today, because they're just not designed for application-oriented experiences.

If successful, it might be beneficial to expand beyond pure applications and into frameworks and plugins as well. Those have slightly different user stories than an application, slightly different requirements, but nothing too terribly onerous to add. Better to stay focused at first, though. Frameworks basically need to depend on development tools which can be a bit trickier to rely on ("C Development Environment" is not something you can cleanly define as a platform), and plugins require dependencies on applications/frameworks on potentially very specific versions (.e.g, this plugin works with LibAudioFoo version 1.1.3, because the authors of LibAudioFoo are asshats and break their plugin ABI every point-release; so you end up needing dependent updates or multiple installed versions, which a pure application has absolutely no need for period).

(Suffice to say, after packaging for four distributions over the last 10 years and doing installer maintenance on Windows for almost as long, I've been putting a LOT of thought into this subject over the years. Just haven't had the gumption to do anything about it because all of the distributions have been very, very hostile to the idea of taking away their control over users' software, and I've seen every similar -- if less complete -- attempt over the years go through a ton of work just to rot out in the sun because the distributions wouldn't accept them. More often than not out of the fear that users will install Evil Immoral Proprietary Software... like games.)

[deanjo]

That almost qualifies them as uber-nerds then.

I wouldn't say so. It is not hard to install most of todays distributions at all. Neither is installing software on them for the most part. Software management programs have come a long way in figuring out dependencies and the likes. Far simpler then in windows, IMHO, where you have to search high and low for one piece of software over here and another over there, etc etc. Macs probably have the simplest installation / deinstallation procedure, drag and drop. Where I do, however, think that linux is still in the dark ages is the many situations where manual editing of files, boot options, etc is required for hardware support. Why the fuck a person has to decide things like v4l2 kernel driver options at boot is beyond me. Hell you show a person a MythTV setup vs a Windows MCE setup and there you will get the puzzled looks and the "Linux is hard" arguments. Linux may support a lot of hardware but getting that hardware to a point where it is usable takes far to much headbanging in it's present form.

[madjr]

1 distro for the avg. user, thats all am going to say.

[ad_267]

I wonder how Desura is going to handle game installation on Linux (http://www.desura.com/). It seems like they would benefit from a project like this.

[elanthis]

I wonder how Desura is going to handle game installation on Linux (http://www.desura.com/). It seems like they would benefit from a project like this.

Probably the same way that Steam on Windows (or some mythical Steam on Liunx) would: by being its own packaging and update system. Some (but not all) Steam games seem to register with the Windows application list, so I imagine Desura and similar apps would enjoy having a framework available to them to do so, but it's not really something they need at all. They've already got all the code to download and install binaries and data and keep them updated.

[curaga]

It's still not uncommon to find software for Windows that doesn't have an installer, but instead comes in a zip file you unpack and then run the exe. This is practically identical to the tarball approach, and novice win users are okay with these apps too. What's your opinion on that?

[devius]

That almost qualifies them as uber-nerds then.

Only if it was arch they installed :P

Like others have pointed out, I also think you're making a big deal out of something not that important. Sure, granny may have a hard time installing third-party software via tarballs, but the average computer user upon stumbling on a problem already knows that typing the problem in google will eventually reveal a solution.

PS: What do you mean by NVN being hard to install? Just the other day (when I found out that there was a linux client... yes, under a rock that's right) I downloaded the resources, client and last patch from the server, uncompressed everything and it was working.