Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] SourceMage fresh install comments

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
  • To: Casey Harkins <charkins AT upl.cs.wisc.edu>
  • Cc: Source Mage Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] SourceMage fresh install comments
  • Date: 09 Mar 2003 21:45:17 -0500

On the sorcery front, here are thoughts:
2) It does? Bah, now I've got to go through and find it. I know that I
wrote stuff to use /proc, but didn't think there was any ps usage. Could
you make abug for this?

4) That behaviour has changed in devel. Currently if you cast a speel
that is already cast it'll resurect it. This'll probably be changed to
some other behaviour, possibly it'll cast it if there a newer version
than what is installed... not sure yet.

As for patches, this is out of my area of expertise, but generaly I
think patches are be submitted to the program author, and then added to
the spel. There has been some discussion on whether the patches should
be included in the spell or as an addional d/l. Don't know the results
of the discussion though.


On Sun, 2003-03-09 at 20:47, Casey Harkins wrote:
> I did another fresh install this past week from the latest iso and have a
> few comments to make. Most of these are probably repeats, but I'll try to
> get bugs filed as needed. I'm using sorcery-devel and the test grimoire.
>
>
> 1) net-tools and init.d spells block for user input. This one I believe I
> even volunteered for a month or two ago, so I'll try to take care of it
> soon if someone doesn't beat me to it. Both spells should "query" if the
> user wants to launch the config dialog, this way it can timeout and use
> (ideally) sane defaults.
>
> The hardest part of this is defining what are sane defaults. Personally, I
> think the network card configuration and init.d script configuration
> should be separated off into two separate utilities that get installed. If
> the user answers 'yes' to the query, it'll launch these configuation
> utilities, if they answer 'no' it'll could instruct them to launch the
> utility at a later time.
>
> For the init.d scripts, the scripts could individually be set to update
> automatically, or not. The init.d configuration tool could be used to
> toggle this on or off, to manually update scripts from the init.d spell
> directory, and to manage run levels.
>
> I previously submitted a pretty thorough network configuration utility
> which can manage the device files in the /etc/sysconfig/network directory.
> I'll volunteer to create a similar tool for managing the init.d scripts,
> but don't want to waste my time if its not going to be used.
>
> 2) sorcery uses 'ps' but the procps spell is not included in the
> basesystem.
>
> 3) fstab is backwards. The non-physical entries in fstab should be listed
> after the physical entries (at least after root). This could probably be
> fixed in the mount.sh init.d script somehow too.
>
> 4) cast'ing a spell that is already cast fails without telling user to use
> the -c option. Here is a simple example. I have wmix installed, I remove
> the cache entry to prevent resurrection and attempt to cast without -c:
>
> root@zorak:~# rm /var/cache/sorcery/wmix-3.0-i686-pc-linux-gnu.tar.bz2
> root@zorak:~# cast wmix
> Preparing environment for wmix
> Collating dependancies...
> Spells are to be cast:
> ---------------------------
> wmix
>
> Do you want to cast these spells? [y]
>
> Preparing environment for wmix
>
>
> Spells that encountered problems:
> ---------------------------------
> wmix
>
>
> I also wanted to say great work to everyone! This is by far the smoothest
> install I've done to date. Only 4-5 spells failed on the first rebuild,
> all because the source was no longer available (shouldn't sorcery
> automatically try the download.sourcemage.org/mirror url?). Also casting
> speed has dramatically increased.
>
> One last question: what should/is the policy on providing patches for
> spells? I have an updated version of the WindowMaker spell that asks if
> the user wants to apply a Xinerama patch. It'd be nice down the road to
> allow the user to arbitrarily include patch files (similar to adding
> configure options). Anyway, should I submit the updates to the WindowMaker
> spell, or should we avoid offering patches that have not yet been
> integrated by program authors?
>
>
>
> -casey
>
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss




Archive powered by MHonArc 2.6.24.

Top of Page