Erich Focht wrote:
I suggest we add a field which shows to which distros we aer compatible.
So Centos.pm would create:
linux_distro => "centos",
linux_distro_version => $centos_release,
and (NEW)
compat_distro => "redhat",
compat_distro_version => $centos_release,
compat_distro_version might need some "translation". The generic-setup thing
would then use the compat_distro, and if it doesn't find it, the linux_distro
entry. Or the other way round.
I don't like this -- "compatible" is too wide of a word. What,
*exactly*, does it mean? How loose do you want to define "translation"?
More specifically, for the 99% of things that are the same between
RHEL and Centos, what about the 1% of things that are different? I.e.,
what do we do when there is something both common and different between
RHEL and Centos? This mechanism does not address that at all. What if
a distribution is "compatible" with more than one other distro? What if
it's only compatible with certain ranges of versions of some distros?
Finally, one more thing on the definitions -- on the far end of the
spectrum, "compatible" could be loose enough to mean, "Debian and
Mandrake are both Linux, so they must be compatible" which is clearly
not true.
I do not think that this compat mechanism is a good idea; it's a
slipperly slope which, if used, will end up with fuzzy definitions and
horrible hackarounds later in the main code base (well, I want Centos to
be treated just like RedHat here and here, but I need to do something
different there and there). If you really want Centos to be treated
*exactly* the same as RedHat, then you should modify RedHat.pm to
recognize Centos (and perhaps rename RedHat.pm to RedHat-and-clones.pm).
Actually I'd prefer to split up Fedora.pm into Fedora3.pm, Fedora4.pm,
etc. When we remove support for a distro, we simply remove the .pm file. Same
for Redhat, instead of building complicated ifdefs into the .pm file (for
recognising the different version strings), it is easier to split them up
across the single files like rhel3.pm, rhel4.pm. The if-block is implicitly
built into the OCA framework, no need to make the distro files recognize more
than one main version. If someone wants code reusage, we can easilly integrate
the common code into OS_Detect and simplify the distro.pm files later.
This seems to somewhat contradict the spirit of your previous paragraph
where you want to make really loose definitions; now you're suggesting
making very tight definitions (making a .pm for each distro version). ;-)
My only objection to this is the amount of code replication that it will
force. All the Fedora .pm files will be almost identical (and all the
RedHat .pm files will be almost identical and ...). If you start
re-introducing code re-usage in there, you're quickly going to return to
the same structure of if's that are currently there, but with an added
level of indirection. So it doesn't seem to buy you anything.
All in all, I don't think it's a Bad Thing to make someone Think before
they remove support for a given platform/distro (vs. just blindly
removing a .pm file). Although this is the weaker of my two arguments,
I think it's worth mentioning. :-)
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
