A few assorted comments/questions/todo items

Here are some assorted notes I made as I was testing familiar over the
last few hours:

1) I noticed that the /etc/rc*.d directories are disappearing from
   most packages. What's the rationale for this? It seems to me like
   /etc/rc*.d is clearly the right way to start daemons and such. Or
   is Familiar policy taking us in some other direction? Speaking of
   which, a Familiar Policy Manual might be a very good document to
   start writing about now, (as tedious as that might be).

2) I know that things have been hectic and we've all been scrambling
   to get familiar v0.4 ready, but I think it's time that we really
   start respecting the Maintainer field in the packages. It's been
   painful for me as I've upgraded packages recently and not known if
   someone else had also made changes that I would obliterate by
   committing my new packages. I am still listed as the Maintainer for
   most of the Familiar ipkgs, (thank you Alexander for taking some
   of them off my hands). By no means do I intend to remain the
   Maintainer on many of these, (although I am interested in
   streamlining the .deb->.ipkg process so I may hold on to the ipkgs
   that came from Debian). If you would like to update a package for
   which I am the Maintainer, please let me know and I will gladly
   give it up for you to maintain. If you don't want to become an
   official Maintainer, then please send patches to the
   Maintainer. I'll also stop updating any ipkgs for which I am not
   the Maintainer.

3) ipkg now supports conffiles in the same way as Debian. A maintainer
   simply creates a control file named "conffiles" that lists each
   configuration file in the package. ipkg caches md5sums for each
   configuration file and checks these during package upgrades. If the
   md5sum matches then the conffile is overwritten with the version
   from the new package. Otherwise the user is prompted whether or not
   to overwrite, (so that customizations are not lost). I've got
   conffiles information in place for several important packages,
   (ipkg, pcmcia-cs, and a few others), but it would be good for
   someone to do a quick audit of files in /etc to make sure they are
   appropriately listed in the conffiles control file for the
   corresponding packages. Any takers?

4) ipkg currently complains about several missing dependencies when
   you install several packages. The "ipkg install
   task-familiar-complete" after a bootstrap install will list quite a
   few, (cpp, debconf, libgl1, etc.). This looks bad. These are really
   false dependencies leftover from Debian packages that we have
   stripped down from familiar. We should probably just strip out all
   of these false dependencies, although a few might be worth a closer
   look to make sure there isn't any real dependency there.

5) Another funny leftover from Debian-stripping is that we have
   packages such as dpkg which doesn't even provide any dpkg
   program. It actually only contains start-stop-daemon and md5sum. We
   should probably rename any such packages and adjust dependencies
   to match.

6) I've absolutely had it with iv. It is terribly broken, (most
   notably on long lines and lines with TAB characters). I ended up
   using ae on the plane, but this was a bit painful too, (a slang
   dependency plus I don't know how to use it). iv *might* still be
   the right thing to include in bootstrap, (especially if the
   author's recently promised update fixes some of the big bugs). In
   the meantime, I will be putting ipkgs together for at least nvi,
   elvis-tiny, and vim-tiny to see what else we might use.

7) I found some bugs in ipkg that I haven't fixed yet, (I also fixed
   several so don't use any ipkg before 0.5 anymore). I need to log
   these in GNATS, (I'll do that after I return from this trip):

   Not necessarily a bug, but I think it was heavy handed of me to
   always call ipkg_install_pending at the beginning of ipkg_main,
   (this is especially surprising/annoying if you run "ipkg update" or
   "ipkg list" for example). On the other hand, I didn't want a user
   unaware that [s]he had some uninstalled packages waiting in the
   pending directory. We could either add an explicit
   ipkg_install_pending call to a first-time post-installation
   ~/.profile login script, (if we decide to add one). Or we could add
   an "ipkg_install_pending" step to the installation
   instructions. Another simple idea would be to just move the
   automatic call to ipkg_install_pending from ipkg_main to
   ipkg_upgrade or something.

   ipkg_upgrade behaves very badly if there is more than one version
   of the same package in Packages. Here's a sample:

        sh-2.03# ipkg upgrade util-linux
        Upgrading util-linux from 2.11b-2 to 2.11b-2-fam1
        2.11b-2
        Downloading
        http://murtnat.east.isi.edu/familiar/ipkg/util-linux_2.11b-2-fam1_arm.ipk
        ...Done.
        ipkg_install_file: ERROR: File
        //tmp/ipkg/util-linux_2.11b-2-fam1_arm.ipk not found

   This isn't too surprising since "ipkg upgrade" is currently so
   braindead. The immediate workaround I would like to do is to simply
   prevent multiple versions of the same package from appearing in
   Packages. The best way to do this would be to update
   ipkg-make-index to only record the most current version of each
   package. Otherwise, this requires remembering to manually remove
   old versions every time we upload a new package. If anyone wants to
   beat me to the update of ipkg-make-index I think that would be
   great. ;)

---
Well, that's it for now. I think familiar v0.4 is really starting to
shape up.
Alexander, let me know if I can help on the documentation front.
-Carl
-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth_at_east.isi.edu
4350 N. Fairfax Dr. #770, Arlington VA 22203	          703-812-3725