On Oct 26, 2005, at 7:15 AM, Erich Focht wrote:
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"?
Sorry that I didn't choose my words careful enough. When I wrote
"compatible"
I actually meant "clone". A clone distro is a distro rebuilt from the
same
sources, which means it has exactly the same library, perl, python and
binutils versions as the parent distribution. So:
- centos, whitebox, tao, scientific linux are clones of rhel
- fedora is not a clone of rhel (although there is limited
compatibility)
Hm. Ok. I can see your point if we restrict this to have a *VERY*
narrow meaning of "clone".
I'm still somewhat dubious, though. If they really are, literally,
just rebuilds of RHEL, what is the difference between Centos, Whitebox,
Tao, and Scientific Linux? I.e., what is the point of having 4
different clones -- are they really different? If so, how much, and
what, exactly, is different? Will it hose us? Does it violate our
definition of "clone"?
Specifically -- if there are 4 different clones, then it implies that
there are some non-trivial differences between them. Is this true?
(honest question -- I know nothing about any of these 4 clones)
I still think this is the simplest idea: add some fields to the $id
hash array
which identify the clones as such and tell us the name of the original
distro. As I'm not a native english speaker, my suggestion of variable
names
is probably bad, but I hope the idea is described sufficently.
cloned_distro => "rhel",
clone_version => $centos_release, # this must be the rhel version!
Yes, I understand you now -- sorry for harping on word selection
before; I didn't fully understand what you meant.
With the generic-setup in place for all distros, we can easilly split
up OSCAR
into distro-specific pieces. Building a complicated overlay structure
makes
this difficult again.
I'd prefer:
distro/common-rpms
distro/rhel4-ia64
distro/rhel4-x86_64
and would have some headache with:
distro/common-rpms
distro/rhel4-common # I could live with this...
distro/rhel4-ia64 # for the original rhel4-ia64 distro
distro/centos4 # centos specific add-ons (urgh.... NO!)
Still, as suggested in one of the previous emails, we could have
overrides in
generic-setup, such that packages in distro/common-rpms have lower
priority
than those in the distro/$distro-* directories.
I don't have much of an opinion on this. I still think there's the
opportunity to find a corner case that violates any of these
situations, but as long as the config.xml can make fine-grained
selections between any/all of the directories, having generic-setup
handle the 90% cases should be fine.
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.
Sorry, I disagree here. The old (and BAD) structure was to have many
places
where some sort of distro and version string was assembled and
interpreted:
many setup scripts and the lib/OSCAR/Distro.pm module. Each of these
contained
a different variant of the if-else block, each of them had to be
updated when
adding a new distro or a new distro version. It was a big source of
trouble.
Agreed.
The job of the OS_Detect/*.pm modules is to detect the distro name,
version and architecture. When the job is done and works for one
distro, this
should not be touched any more. A new distro should not need to touch
this
code. When the format has stabilized, all you need in the
OS_Detect/*.pm
modules is a few distro specific constants:
# rhel4
distro_file=>"/etc/redhat-release";
distro_match=>"Red Hat Enterprise Linux WS release 4 \(Nahant Update
(\d)\)";
distro_name=>"redhat";
cloned_distro=>"";
cloned_version=>"";
cloned_update=>"";
If the string matches, we pick $1 as update version, the rest can be
hardcoded. If the string doesn't match, fail. Multi-line matches
should also
work.
All the rest is just common code which could go into OS_Detect.pm
(including
arch discovery). $cloned_version needs to be computed sometimes (eg:
tao 1.X
is a clone of rhel3), therefore it should contain a string which can
be an
argument of eval.
Here one more example:
# scientific linux 4.X
distro_file=>"/etc/redhat-release";
distro_match=>"Scientific Linux SL release 4\.(\d) \(Beryllium\)"
distro_name=>"scientific_linux";
cloned_distro=>"redhat";
cloned_version=>"4";
cloned_update=>"\$distro_update";
Having the version hardcoded gives us the advantage to not need to
catch
unsupported versions. Either the string matches, or not. No other check
needed.
I see you point here, but I guess I see this as an attempt to
generalize too much. What about when we support other operating
systems? So I wouldn't want to force this exact scheme on all
OS_Detect components (e.g., I have no idea how Debian works -- whether
it can just match a string against a file, etc.; OS X does not).
..although I can also see the point of optimizing a common case --
RHEL's and clones. Perhaps such a scheme like this should be
abstracted into a common subroutine in a RedHat.pm somewhere that all
of the RHEL's and clones can call and get customized $id to return...?
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. :-)
With the help of SVN this is really not a problem.
Just because it's possible to make recovering a file from history
doesn't mean that it's a good idea. If you have to recover something
from history, for example, that means you screwed up. Plus, recovering
data from SVN history also applies to screwed up "if" logic just as
much as it applies to recovering deleted files.
My only point here is that raising the bar to help prevent stupid
things is rarely a Bad Thing.
This is all just my $0.02 -- but as we have said in OSCAR many times,
he who implements, wins. So if someone implements it differently than
I would have, then so be it. :-)
--
{+} 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
