[Bug 667] New: <patch> element support for download and uncompression
jwrober at linuxfromscratch.org
Tue Sep 23 08:38:51 PDT 2003
Kevin P. Fleming wrote:
> The other option is to do as James suggested and just have one set of
> source for each handler, and let the handler itself check the version
> and act appropriately. I'm beginning to think that's a better option.
Hey, I knew I was good for something :-)
> And yes, I realize that if the user decides they want to take advantage
> of version 3.2 syntax for one element, they'd have to upgrade their
> profiles to incorporate all other version 3.2 changes. But this system
> would never cause existing profiles to break, unless I've missed
> something :-)
This is why I proposed that idea. If you want to allow a configure
script option like --with-min-dtd-version=3.0 or something and then when
you comile it the binaries will only support version 3.0+ of the dtd.
Or if you don't specify anything to configure then the binaries support
all versions and use the value of the dtd from the main profile file and
would then spit errors if you mix dtd syntax in some of your profile
files since you are not consistent. That way the binaris can support
and dtd version and keep your coding to one file per element (e.g.
execute.c and patch.c, etc.)
I am not a a coder by any means, so my idea may cause a lot of burden on
the three of you. I would just think, though, that this would be easier
down the road as the dtd changes to support bigger and better stuff and
will reduce the number of seperate source files hanging around. You
would also have to document somewhere the reasons and "procedure" to
create a new source file that handles a new dtd syntax version. I would
think that would be more work as well.
More information about the alfs-log