Autopatch plugin need some testing
Duncan Gibson
duncan.gibson at xs4all.nl
Fri Jun 29 09:18:53 CEST 2007
> To try it, create a $MOONBASE/zlocal/_patches directory. In this
> directory create a $MODULE directory that correspond to the module
> you want to autopatch. Put your patch files in that dir and run
> lin $MODULE. If you want a patch only to match a certain version,
> create $MOONBASE/zlocal/_patches/$MODULE/$VERSION and put your
> patches there.
Ratler, you clearly have a particular itch that this patch plugin will
scratch, but I don't quite see what the major advantage of a separate
_patches directory outside zlocal will be.
I can understand that having some means of associating a patch with a
module without having to modify the module files may be an advantage
if you want to apply some local customisation that does not really
make sense for the rest of the Lunar users. But why does the _patches
directory need to be separate. Would it not make more sense to run
lvu edit $MODULE to create a zlocal copy, and then create a _patches
in that copy? Generic patches could live in zlocal/$MODULE/_patches
and version specific could live in zlocal/$MODULE/_patches/$VERSION.
Tools that track local customisations would only need to look in
zlocal and not somewhere else too. [I thought that I'd posted such
a script to the forum or ML last year, but I can't find it now :-( ]
Yes, the zlocal/$MODULE/DETAILS and associated files might appear
frozen at a particular version, but this is no different to having
the current version in the main moonbase. So when you request a given
version of a module [lin -w ?] you are already ignoring some of the
configuration in DETAILS so this would be no different.
Just my non-dev $0.02 worth to start the discussion ball rolling.
Cheers
Duncan / engelsman
More information about the Lunar-dev
mailing list