[Bug 667] New: <patch> element support for download and uncompression

James Robertson 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.

My $0.02


More information about the alfs-log mailing list