Re: [dev] [OFFTOPIC] Recommended meta-build system

From: Dmitry Maluka <dmitrymaluka_AT_gmail.com>
Date: Mon, 1 Feb 2010 12:46:55 +0200

On Mon, Feb 01, 2010 at 09:48:37AM +0000, Anselm R Garbe wrote:
> IMHO such a package manager is not needed, all we need are static
> executables of each tool what I try to achieve with static linux. Only
> exception are config files for daemons and tools, however this is all
> achievable using git or rsync for upgrading.
>
> So there is really no need for a package management system ;)

I was talking on a more general problem. Though it's just a concept or
maybe a dream. :) In this world, developers distribute their software in
native source tarballs containing human- but not machine-readable
instructions for building, installation, uninstallation etc. Many people
prefer manual searching, downloading and installation just because they
want to deal with native software packages provided by software
developers, not intermediate maintainers. Why not automate our actions,
retaining flexibility and transparency? No package repositories, just
package metadata servers with package URLs; developers registering their
(native) packages at that servers; servers synchronizing metadata
between each other; define the metadata format allowing automated
package management. Though people may still do all the stuff manually.

And, what was this thread about? Annoying inconsistency of system
interfaces (due to bloated and at the same time incomplete standards)
leaves us without guarantee that something will work somewhere. Aren't
we sick of that? In a good world, software developers would follow
systems approach when making their software be used world-wide. They
rely upon simple well-defined interfaces. Interfaces are to be
registered at metadata servers too. Packages are tarballs to be
downloaded, untarred and done some actions defined by package metadata
(usually make install, make uninstall etc.) after cd'ing into the
untarred directory. (That's one of possible ways.) If something doesn't
work, it means a bug in implementation of some package, i.e. behavior
violating some of the documented interfaces. That bug can be simply
discovered and fixed. Nice dream, isn't it?
Received on Mon Feb 01 2010 - 10:46:55 UTC

This archive was generated by hypermail 2.2.0 : Mon Feb 01 2010 - 11:00:05 UTC