On Sat, Jan 09, 1999 at 12:53:41PM +0100, Raphael Hertzog wrote:
> Le Sat, Jan 09, 1999 at 02:21:53AM +0100, Torsten Landschoff écrivait:
> > I do not like the idea to have a fixed database. That's not Unix style. And of
> > course that is not the goal. It's another implementation detail.
>
> Why not ? I think that the database is useful, I dislike the idea of cookies
> that are generated... With the database you can easily change many things
I do not oppose the idea of a database. Of course we need some kind of
database. But I do not think it is ideal to have a local database but we
should specify an interface to this (virtual) database. Then we can use every
kind of repository as our database.
> using queries or little scripts, but with the cookies system, this won't
> go. And an expect script will fail if the strings displayed change
> beetween two versions but a database configuration won't have this problem
> because the key will not have changed. And what about the day where
> postinst will be internationalized ?
Right. I do not want to have a description of the parameter as key but an
unique identifier. The description in english should be with the package as
fallback if you install something which need a new option for which no
description is available.
This is a problem we have to address. With each new package there might be a
new option so we have to update the configuration database or at least the
description of the options. With my proposal we would at least have the
english description ready which would suffice for advanced users (like me).
> We do need a configuration database in order to achieve our goal. However
> i'm pretty against using it as windows-like registry. And it cannot be a
> windows-like registry because it won't manage per-user configuration which
> is much used by Unix softwares.
We could even interface dpkg-option to a network registry on an NT server if
we knew how to access it. I do not like the binary registry either but it has
its benefits. For example the access is fast compared to our ascii files. This
does not matter for small files but e.g. /var/lib/dpkg/status respectively
available it is inappropriate at least for slow machines. That's the only
think I dislike of dpkg - dpkg -i file.rpm takes way to long on slow machines.
I use Debian on a 386sx for example :)
This is not an issue on my PII but I might become a problem if Debian grows as
fast in the next years. We should think of a binary representation of
/var/lib/dpkg/status but this raises the risc of corrupted binary files...
> Cheers,
> --
> Hertzog Raphaël ¤ 0C4CABF1 ¤ http://www.mygale.org/~hra/
cu
Torsten
Attachment:
pgpybnWVWogR3.pgp
Description: PGP signature