You commented on a really really really old document, most of what is written in there isn't valid anymore.
I think that a "/stow/package-vers_N/"SUMMARY directory is better, independent of the number of files that we will need. That is what will be used probobly. [...] > 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. Those scripts won't exist. Providing them would be hard, since the package manager is a file-system, and having a file-system run the commands in those script could cause quite funny things. > 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. The package will always be installed if you link it into /stow. > 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.q Why do you think that using symlinks is a bad idea by default? > 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. Not knowing what the GNU Source Installer does, I can't really comment on that. Installing packages from source is done using the classic three commands: configure && make && make install DESTDIR=/some/place And then creating a symbolic link from /some/place 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. > 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? Dependencies are not important, they are only used by a front end, and the scripts won't be avaiable to begin with. Most of the details are sketchy, but what generally should be done is known. Cheers. _______________________________________________ gnu-system-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-system-discuss
