Re: [Helidelinux-devel] Package manager
Status: Abandoned
Brought to you by:
rveen
From: Hui Z. <zh...@wa...> - 2004-03-16 19:35:03
|
Hi, Bennett, thank you for your rich information, I will looking into rpm when I get time. On Tue, Mar 16, 2004 at 05:30:43PM +0000, Bennett Todd wrote: > > The minimum I believe is just install and uninstall. > > That's definitely not sufficient; a software package manager must > also offer inventory (what packages are installed), dependancy Using lfsbuilder to install or uninstall all the packages will provide the inventory with no extra effort. Dependancy as we discussed could be devided into building dependancy and running dependancy. Building (or installation) dependancy is something the installer(lfsbuilder) should consider, I will have to work on that even don't want to implement an package manager. Running dependancy is something the uninstaller need to consider. When uninstalling a package, it may broke other packages' running dependency, thus have to raise users attention. > management of some sort (what packages does this package depend on, > at a minimum), integrity checking (are the files in this package I am planning on a package fetcher (works through internet). If the signature file or MD5Sum is available along with the package, the fetcher is responsible to check the integrity. For custom binary package such as bent distribution, once the fetcher understand where the signature can be retrieved, it checks the binary package also. As for individual files of an installed package, install-log can help. > intact on the system?), and pre/post install/remove scripts. Most are system configurations (am I right?), these are nasty. > To look at the set of features a software packaging tool must > support to compete with rpm, consider some tasks that it must > assist in: > > - Easily wrapping new packages I am most insterested in installation directly from source, but when you think about it, instead of install, one can wrap into packages with slight twist. The catch is select a good package format. BTW, as the work in LFS project indicate, the host tool chain can play an important roles, how redhat or debian manage this problem? > > - Easily updating existing packages to track new versions of the > up-stream software > > - Easily wrapping packages that apply patches to the upstream > software, either to fix bugs quicker than the upstream integrates > the fixes, or to adjust the package to build the way you want it > on your dev platform > > - Assist in automating complex package installations; it should be > possible to build something like "apt", that can be pointed at a > package repository, and automatically install all prerequisites > > - Automate installing systems --- think Sun's Jumpstart, Red Hat's > kickstart. A fully automatic system build to a "profile" (defined > as a package list) is vital for enterprise computing. Updating the > build to track updates to packages must be easy. > > - Automate delivery of patches and updates; the update process must > be so robust and safe that it can be automated over tens of > thousands of machines with a near-zero failure rate and clear > error reporting. > > - Automate inventory of system configuration; with simple scripting > you should be able to populate an RDBMS with every version of > every package installed on every system in a large enterprise > Good digest. -Hui Zhou |