[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Package Management System
From: |
Leonardo Lopes Pereira |
Subject: |
Re: GNU Package Management System |
Date: |
Sat, 10 Sep 2005 15:03:03 -0300 |
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