Re: [9fans] nupas update

[EBo <ebo@sandien.com>]

>>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 --