Re: Package format/management ramblingss

[Soeren D. Schulze]

Richard Stallman wrote:
>     Yet another problem are conflicting versions.  In Debian, for
>     example,
>     two different installations normally conflict.  As a compromise,
>     unstable development versions, for example, are provided as
>     separate
>     packages.
>     Every problem of this kind is solvable, but a solution does not
>     exist
>     in all cases; so a *general* system-wide and program-independent
>     solution would be desirable.
>
> There's an idea in my proposal for this: The symlinks from /packages
> that cause a package to virtually appear in /bin and elsewhere can
> have names that virtually rename the executables in the package.
> My idea is that these executables would get the other files
> of the package out of the directory that the package is really
> running from.  That way, multiple different versions could coexist.

Just to make sure I understood you correctly:
Your attempt is to make different versions generally not conflict --
completely different to existing package managing systems -- and link
the system-wide preference to a file name which not contains the
version number.  Right?

It sounds good to me because users would find system defaults when
executing programs.  If they have their own preferences, they could
make aliases for themselves.
And, as far as I can see, it would not even necessarily require the
Hurd to work on.
The only potential problem would be making all programs expect their
configuration files and shared data in files and directories containing
the version number.

>       It is the same problem
>     if you have a (physically :) portable computer and work in two
>     separate
>     networks with it and need independent configurations but do not
>     want to
>     install a new system for each environment.
>
> We could imagine using special names for the symlinks in another way
> to help address this problem.  They could associate the various
> installed versions of a package with different configurations.
> By selecting your configuration, you could control which installed
> packages "show up" virtually in files in /etc and its subdirectories,
>
> Thus, /package/address@hidden -> /disk/foo-a and
> /package/address@hidden -> /disk/foo-b would set up for configuration
> variable foover to control which of these two gets installed.  Set
> foover to hay, and you get foo-a.  Set foover to wow, and you get
> foo-b.

I do not think configurations have to be associated with versions
necessarily, although it may be the main case independent  
configurations are desirable in.
Nevertheless, variable substitution (I assume that is a kind of what  
you meant) in file names is a very nice idea.

>     You could, as every user else on your system, act in a kind of
>     chroot
>     environment and compose your own user-specific directory tree!
>
> Do you mean something like /package/foo -> /disk/foo-$foover?  Then
> you would set configuration variable foover to either a or b?  That
> could be a good feature.  We could combine the two by using $ in the
> symlink's name, too: /package/address@hidden -> /disk/foo-a, for
> instance.

Am I right this is similar to the case above, but with real shell
variables?

But what I actually meant was:
You are in a kind of chroot environment and have the directory /disk
which contains the directory tree of the system.
You merge /disk/bin, /disk/sbin and /disk/home/<user>/bin to /bin,  
which you have full access to in your environment.  (of course you are  
not allowed to modify files you get from /disk/(s)bin)
Accordingly, you merge /disk/share and /disk/home/<user>/share and
/disk/cdrom/share (bad name), where you get additional data from, to
/share.

If you have installed foo locally in /disk/home/<user>/bin because your
administrator does not like it, it is in the same directory as the  
files from /bin now.
Accordingly, if the CD-ROM contains some data for foo, it is now found
in /share/foo as well as everything from /disk/home/<user>/share/foo.

the disadvantage: chaos ...

But for most applications I had considered, your solutions are better
anyway.

>     2. Also desirable would be the feature of ``preferring''
>     symlinks,
>     which especially becomes interesting with the feature of
>     directory
>     merging:
>
> This could also be a good idea.  How would you specify preferences?
> Here's my idea: make a subdirectory in /package called
> /package/conflict-resolution.  In that subdirectory there would
> be ordinary files, and each file would have a list of package names.
> If one file said "foo bar", then foo would be prefered to bar
> in the event of a conflict.

We are seemingly talking at cross purposes ...

You regard a conflict where two packages provide the same file?

I actually regarded conflicts in the case above when merging
directories.

> Normally, the conflict would be treated as an error.  The system
> should not silently resolve conflicts; it should warn the admin.  The
> admin
> would then choose how to resolve them.

In the case of packages, yes.
In the case of directories, I would not consider a conflict fatal.  If,
regarding the case above, /disk/cdrom/share/foo and
/disk/home/<user>/share/foo provide the same file, just prefer the
CD-ROM because you have included it to get some additional data that is
not found in your installation.


Soeren Schulze