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

Kevin P. Fleming kpfleming at linuxfromscratch.org
Tue Sep 23 08:06:34 PDT 2003


Neven Has wrote:

> Well, it's a good idea for solving the versioning problem for smaller
> syntax changes.  But for the same reason, it will encourage them,
> which I'm not sure it's a good idea.
> 
> It's confusing for the users, and probably annoying when their
> profiles become obsolete.

I think I may have described this poorly, and I have also realized 
that the wildcards are not the way to go. Instead, each handler should 
have the minimum/maximum profile version it supports (an inclusive 
range). Let me take a stab at it again:

Today, we have src/handlers/execute.c, which supports version 2.0, and 
src/handlers/new-execute.c, which supports versions 3.0 and 3.1. Under 
my proposed scheme, we'd have (with the syntax versions they'd support):

execute-2.0.c -> execute-2.0.so (2.0.0-2.9.9)
execute-3.0.c -> execute-3.0.so (3.0.0-3.1.9)

Each module would continue to support the same profiles they do today. 
However, let's say someone comes up with a cool enhancement for 
<execute>, and we decide to make that version 3.1.6. So now we'd have:

execute-2.0.c -> execute-2.0.so (2.0.0-2.9.9)
execute-3.0.c -> execute-3.0.so (3.0.0-3.1.5)
execute-3.1.6.c -> execute-3.1.6.so (3.1.6-3.9.9)

This would actually make it easier in the future to allow the user to 
build only the handlers they need to support their profiles (like in 
my case, I've never had 2.0 profiles and never will).

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.

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 :-)





More information about the alfs-log mailing list