Abdulaziz Ghuloum <[email protected]> writes: >> I'll tackle dependency management next, probably by porting >> aptitude's resolver algorithm; HTTP and ZIP file support should be >> relatively easy to add; the hooks to do so are in place. > > Great! This all looks very good. > :-)
> >> For what it can do ATM: >> >> - Scan bundles (which are just directories, until ZIP support is >> added). This mostly involves creating an "inventory" for each >> supported category; there is mostly one category I'll care about for >> now: "libraries", containg R6RS library files. The package >> inventories each map an hierarchical namespace to files in the >> bundle. > > Categories may be "libraries", "documentation", "programs", and the > like, right? Or do you mean something else? > Right. > If a bundle is a set of packages, and each package contains a set > of files, how do categories fit in? > A package may contain several inventories (namespaces for files) which point to the real pathnames in the package's bundle. Each such inventory forms a "category" of files. The intent of categories is to allow for installing files from different categories in different places, or even not at all (one could for example tell the package manager to just install libraries and programs, but not documentation and examples). Additionally, the inventory creates a virtual namespace that is not necessarily reflected by the filesystem namespace in the bundle -- you can rearrange the filesystem tree to match what is expected for the category. For illustration, consider a bundle containing dorodango and all its dependencies. The filenames pointed to by the arrow are relative to the bundle's top-level directory. Note how the library filenames for the srfi and dorodango packages are identical on the left and right side, but not so for spells: Package: dorodango Depends: spells, srfi Category: libraries dorodango/inventory.sls (-> dorodango/inventory.sls) dorodango/bundle.sls (-> dorodango/bundle.sls) [...] Category: programs doro.sps (-> scripts/doro.sps) Package: spells Depends: srfi Category: libraries spells/foreign.sls (-> spells/spells/foreign.sls) [...] Package: srfi Category: libraries srfi/%3a1.sls (-> srfi/%3a1.sls) [...] > Maybe I also need to know what bundles are really for. (e.g., why > not only packages that have categorized files?) > I think bundles are a natural extension of the package concept, and are useful in some situations; you could for example publish a bundle of your application with all (and known-good versions of) its dependencies. >> - The package database is designed to keep track of not only installed >> packages, but packages available from repositories as well; on top of >> that data, "smart" dependency resolution can be implemented. > > Good. (whatever "smart" may mean) > I've started skimming the aptitude dependency resolution paper[0], and think I'll implement the algorithm outlined there; I think it should be at least "good enough" for our purposes :-). [0] http://hg.debian.org/hg/aptitude/head/file/11f5f723d2c4/src/generic/problemresolver/model.tex >> - Destinations can specify how a (package, category, inventory-path) >> triple is mapped to a pathname. > > There should be some sensible default setting here, otherwise, it > may be too complex for starters. > Yeah, sure. There'll be a sensible default configuration that will make it useable without configuring anything besides adjusting your ${IMPLEMENTATION}_LIBRARY_PATH accordingly. Regards, Rotty -- Andreas Rottmann -- <http://rotty.yi.org/>
