Re: GNU Package Management System

[Leonardo Lopes Pereira]

I am sorry, I didn't saw that a proposal to create a GNU Package
Management System already exist. So, I will comment the old's proposal.

> * Package format
> All nodes that are related to the package format shall start with a
> plus-sign (+).
>
> [Clarify the binary format for the file, it will be just a flat
>  tgz-ball.]
>
> [Maybe dump them in a {stow} directory, and remove the + sign from
> them, this will create less clutter in the file-listing if the amount
> of nodes provided by stow becomes large.]

I think that a "/stow/package-vers_N/"SUMMARY directory is better, independent
of the number of files that we will need.

[...]
> The following are non-interactive scripts.
> ** +post-install
> ** +pre-install
> ** +post-deinstall
> ** +pre-deinstall

What that scripts will do? IMHO, We do not need most of them, but we can 
provides
something that allows the use of that kind of scripts.

[...]
>> `,depends' is list of unfulfilled dependencies in the following
>> format:
>>
>>  PACKAGE (PREDICATE VERSION), ...
>>
>> Where PREDICATE is one of the following predicates: < <= = > =>.  If
>> PREDICATE is null, then it defaults to equal.  If the whole
>> `(PREDICATE VERSION)' clause is absent, then any version of the
>> package PACKAGE will do.  Whitespaces shall be ignore.
>> 
>> If all dependencies are fulfilled, then this node will not show up in
>> the file-listing.
>
> Information like this should not be stored in the package, because it
> varies, and it depends on other things aside from the package itself.
>
> So I would put this information somewhere else, perhaps under /var.
> It could be one large file describing the entire state of package
> dependency satisfaction.

IMO, the package dependencies list will come in a file on SUMMARY, stowfs will
read it and, if there is no problem, the package will be 'linked' to /, if there
are problems, it will return the list of dependencies that are no provided on
something like /stow/NDEPENDENCIES, a list of non-provided dependencies that are
required by any package with the name of the packages that require them. 

> 1) Unpack the package (if it is already unpacked, skip to 2).
> 2) Copied, or symlinked into /packages.

They are the same step, user can extract the package directly on /stow, and the
uses of symlinks is a bad idea by default. Symlinks could be used to test a 
package
but not to install a package definitely.

> 3) The following are performed by stow:
>  a) Check dependencies, update `,depends' node accordingly.
I think that a unique list of dependencies is better than a lits for each 
package.
If there are problems on deps, the installation stop on this step.

>  b) Run pre-install script.
>  c) Merge package into the file-system, skipping any nodes that are
     related to stow, or the package format.
>  d) Fix files according to what is described in `+manifest'.
>  e) Run post-install script.

You forget to describe how packages installed from source may be used on that 
case, I think
that we can work with GNU Source Installer to it be the way to create packages 
from source and
put the binaries on '/stow/package...' Better than ask people to install 
binaries on
'/some/place', create the package infraestructure and create a symlink to 
/stow. 

> * Deinstallation of packages
> The following steps happen when one deinstalls a package:
> [Should we store a backup of changed files?]
IMO, only if user want's it, something like debian does, 'aptitude purge'
remove the changed files, but 'aptitude remove' doesn't.

> 1) Check what dependencies break.  Do this recursively until all
>  dependencies have been cleared up.
Okay.

> 2) Run pre-deinstall script.
> 3) Unmerge the package
> 4) Run post-deinstall script.
> 5) To completely remove the package from the system, we just remove
>   the node /stow/PKG-VER here, otherwise this will be a no-op.

Okay, but what will happen if a person try to do 'mv /stow/package-vers_N 
/dev/null' without
check dependencies or runs pre-deinstall and post-deinstall scripts?

To uninstall without remove a package could be rename it to 
uninst-package-vers_N.




-- 
---
leonardolopespereira at gmail.com

GNU Privacy Guard (GPG)
ID da chave: 83E8AFBF | servidor: keys.indymedia.org
gpg --keyserver keys.indymedia.org --recv-keys 83E8AFBF

signature.asc
Description: This is a digitally signed message part