cvs commit: www/alfs news-2003.txt

jeroen at jeroen at
Fri Oct 17 06:17:39 PDT 2003

jeroen      03/10/17 07:17:39

  Modified:    alfs     news-2003.txt
  Updated ALFS news; fixed locations of Kevin's builds.
  Revision  Changes    Path
  1.6       +19 -1     www/alfs/news-2003.txt
  Index: news-2003.txt
  RCS file: /home/cvsroot/www/alfs/news-2003.txt,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- news-2003.txt	5 Oct 2003 12:41:36 -0000	1.5
  +++ news-2003.txt	17 Oct 2003 13:17:39 -0000	1.6
  @@ -4,14 +4,32 @@
   Section: alfs
  +Title: My personal wishlist for nALFS
  +Author: Gerard Beekmans
  +Date: 2003/10/17
  +		<p>Thought I'd bring this up, a few things I'd like to see in nALFS.</p>
  +		<p>Becoming more of a package manager. I'd like to be able to uninstall packages as well. It's a simple matter of parsing the log file and removing the files/directories that were created. It'll be easy to write a shell script to do this, but if nALFS had a built-in way of doing this, it would be great.</p>
  +		<p>Having the above feature would make upgrades nicer. I usually use two methods of upgrading software:</p>
  +		<ol>
  +			<li>Uninstall old package, install new one. This is the best way to get rid of cruft that'll build up otherwise.</li>
  +			<li>Install without uninstalling. Especially when doing libraries, it's better to keep some libs around so all other apps remain working and relink those apps at a later time.</li>
  +			<li>A third uninstall could be selective, but harder to uninstall: put files in categories. Ie certain lib files can be removed without breaking most apps. An app will most often be linked to so the itself could be removed when removing a lib prior to an upgrade. It'll be more work to implement this, but a feature <em>Uninstall libblah except the crucial files apps use</em> would be nice, eventually...somehow.</li>
  +		</ol>
  +		<p>But the basic package maintenance is what I am looking for: uninstall methods so upgrading is made easier.</p>
  +		<p>Lastly, easier way to do the profiles. Sure I got scripts so I run <code>./newpkg packagename</code> and it'll fetch the md5sum from /usr/src/sources/packagename.tar.bz2 and use a template xml profile to fill in the blanks. Upgrading a version is somewhat harder, I don't have such scripts yet. It'd be nice if something is shipped with nALFS that can be used for profile management. There's some stuff in the 'profiles' CVS module on the server that I put together myself, but it's nowhere near great.</p>
   Title: [CFT] nALFS-1.2.0-gnubuild-pre1.tar.bz2
   Author: Kevin P. Flemming
   Date: 2003/10/05
  -		<p><a href="">nALF-1.2.0-gnubuild-pre1.tar.bz2</a></p>
  +		<p><a href="">nALF-1.2.0-gnubuild-pre3.tar.bz2</a></p>
   		<p>OK, here it is, ready for the first round of testing. This is identical code to current CVS, but the build system has been completely changed. The tarball grew significantly, because the "proper" way to include the GNU build system makes copies of some large files in the distribution image. Also, the tarball currently includes a large set of code that is not used, but will be used when I enable compiling a completely static nALFS (not yet working).</p>
   		<p>Normal users can follow the same instructions as always: unpack, configure, make, make install. There should be any significant changes noticed, other than the build will be a lot "noisier" and the final libraries installed into $(prefix)/lib/nALFS have different names. Functionally there should be no change, though.</p>
   		<p>There are some additional things to note for maintainers; James, if you are reading this I can send you that information for your <em>developer's guide</em>. Tomorrow when I am not so tired I will compose a message listing all the improvements in this version </p>
  +		<p><em>Update 1: <a href="">pre2</a></em></p>
  +		<p><em>Update 2: <a href="">pre3</a></em></p>
   Title: ALFS Roadmap

More information about the website mailing list