Re: Compatability with FreeBSD Ports [debian package tools]

[Raphael Marmier <raphael@xxxxxxxxxxx>]

Joerg Sonnenberger wrote:
> On Thu, Aug 18, 2005 at 06:29:43PM +0200, Gabriel Ambuehl wrote:
>
> > If anything, it should be thought further (and some are already pressing
> > in that direction, notably Xen and VMware ESX): self contained
> > single purpose OS instances.
>
>
> A nice hype, but IMO a nightmare for administration.
>
>
> > One machine might easily do both web and mailserving, but it would be
> > more secure to isolate the services...
>
>
> It's called separate user accounts in Unix.
>
>
> > A package manager that can do something like that would be truly innovative.
>
>
> No, because it wouldn't be package mangement at all. You end up with
> extracting a tarball into a location and removing it for uninstall,
> pretty much like Windows, just without messing in
> C:\Windows\System{,32}.

Certainly not. A sandboxed app would be built by installing packages 
_into_ it. As as said, this is why it must be managed by a high level 
program, that not only gives the operator a clear picture, but allows 
him to upgrade whole "sandboxes", upgrade a single packages, a single 
package in all "sandboxes", etc...

As per config files, sure, this can be a pain. But nothing prevents to 
be smart and inovative, and have the package manager provide a list of 
the config file of all installed instance of a given package, along with
the modification date, and why not, diff between them, revision conrol, 
. .. once the system is solid and predictable, you can put the wizardry 
in managing usefull info: the configs.

Frankly, are there so many dependency packages that need configuring 
beyond the defaults? Most of the time, I bet you need do so to taylor 
them to their dependent package. At this point, its really the same. I 
doubt there would be so much real config duplication.

All in all, you spend a little more energy and disk space at the install 
phase and maintenance phase, so you spend no energy in keeping the 
system from derailing, and no energy and disk space at the removal of 
components.

In the current scheme, you spend as little energy and disk space as 
possible installing. Then spend vast amounts of energy at keeping the 
system from gaining entropy, then spend a fair amount of energy and a 
some disk space at the removal of components.

In the end, we are no so far from the windows world ;)

Raphael