>>I think you >> can go a little further: the /installed/$i file on >> disk can contain info for binding the installed >> package onto /. Then, the /installed/$i file >> resulting from the binds can contain removal >> procedures. >> >> I'm not sure what would be the most comfortable >> from a use perspective, but it's an idea.... > > I think it's worth trying out. I just don't have the time right now. > > So, if we just go with the dircp approach, and copy the files in, what > I hear is missing so far: > - I don't put the installed info into /installed; should I just go > ahead and fix that? > What else?
I too have been interested in this, but I come at it from my experience with portage. The following are things that I would like to either see added or would like to try to contribute as time allows: * versioning support and control - helpful for determining exactly what software is being run, and facilitates developers being able to configure machines similarly by providing the installed package list (called world in portage parlance). * ability to specify stable and experimental versions of a program - so we have dependable installs and still can support the bleeding edge * package masking and unmasking - sometimes a particular package is determined to be buggy on a particular system or configuration and we need to be able to mark it as "do not do this" * live vs. predefined versioning - by convention packages in portage are based off of specified versions. They do provide a mechanism for "live" updates. This is done so that pulling the source tree does not roach some part of the system. * dependency specification - package developers know exactly what dependencies are required, and should be able to specificity what versions of libraries, etc., should or should not be built against. * patch ability - adding the ability to specify specific patches in the package system facilitates maintenance and specialty hardware experimentation. * checksum on all associated files - security, but also assures that I did not do a boneheaded move and modified something. * package associated installed file list - each file on the system is associated with a single package which protects it for being hammered by another package, and this facilitates dependable uninstall operations. * auxiliary trees - called overlays in portage, allows different forks to maintain their own changes separately (this would be particularly useful for migrating between 9atom and the canonical source tree). * cross platform and alt root support - this allows us to build for different target platforms which might be unrealistic to have an entire installed platform like the styx-on-a-brik. As a note, the above were some of the motivations behind my Gentoo based GSoC application (I already have a list of over 30 points to consider in my notes). All of the above functionality is available in portage, but portage is written in python; which is to steep a requirement for a useful pla9 build tool IMHO. Hence my plans to writing it in rc if I end up developing this functionality. Also, I only see a small portion of the above as being required for my current modeling work (namely versioning, dependencies, and cuecksums), but I have found the rest of the functionality unbelievably useful from supporting embedded systems to beowulf clusters. EBo --
