This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

current packing systems awful

Posted by: Anonymous Coward on March 08, 2007 09:08 AM
I hate the current packaging systems. If Linux distros were owned by proprietry companies I would swear the reason for them is to lock people into the distros.

The operating system and the applications should be seperate - they are different things. I want to get the apps from the authors, not from a distro specefic repo. Why?

Because often the app you want isn't in the repo. What do you do then? Compile from source? Then you become (or have to become) a de-facto software developer, who will need to understand and debug C compile listings. No thanks.

The difficulty with installing software, a process that should be so simple, is the shame of the software industry. It is difficult not because its inherently complex, but because the underlying infrastructure in the operating system has been designed without consideration of installing software. If the native file system software and api's supported a proper naming system and local addressing the problem would not even exist in the first place.

Its like designing a car with the steering wheel in the boot. Of course its hard to steer, but it wouldnt be with the wheel in front of the drivers seat.

But operating systems / file systems are not designed with software installation in mind, but with the assumption that the operating system and applications are a complete whole (which they are not), or that the system will be set up by an skilled IT department (which most arent).

As impressive as zero install is, I still think it is more complex than should be needed, as it is a bolt on solution rather than designed into the low level system infrastructure.

The operating system should support in built meta data which allows for the proper run time identification of shared files and looking for them using local references (e.g. the application directory first, then through other outer layers).

I think all application libraries should be able to be located within the applications directories, and the op sys should look there first. It can later determine if an exact same library is already loaded in memory and elect to use that (possibly under user control). Libraries should be shared in memory, but not necessarily on disk. Disk space is in abundance and very cheap. No one cares about saving space for shared libraries these days.

How about this simple scenario. Application (app) is started from its own directory (~home/app). It then wants to load libproc.so. This library is in the app directory (e.g. ~home/app/libproc.so). Operating system calcualates the hash for this library (or has it stored as metadata from a previous run) and examines list of hashes of currently running shared libraries to see if its already loaded. If it is, use it. If not load the local copy and use that.

Cant it be that simple?

Applications would be available on web sites as tar files containing ALL the required libraries. Installation would involve only de-archiving to a named directory. Executing would involve running the binary executable from within that directory. Everything else would be automatic.

#

Return to Zero Install: An executable critique of native package systems