Hi Jeff,
On Tuesday 25 October 2005 14:55, Jeff Squyres wrote:
> 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.
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)
We can (and already do) treat clones as if they were the originals. Most of
the OSCAR packages for RHEL were actually built under CentOS or
ScientificLinux. If an OSCAR package fails to work for a clone but works for
the original, then the clone distro is broken badly and this is not our
problem. I mean: if we hit the 1% difference (which is IMHO actually much
less, say 0.01%), then we are using some feature which we better shouldn't
(eg: redhat string in some files, hat recognition in the logo). OS_Detect is
here exactly for this purpose: to get us rid of the need to check for the
contents of the /etc/*-release files.
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!
> 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).
For clones, you don't want differences at all. You want them treated _exactly_
like the original distro. If there are differences to the original distro
(like between fedora and rhel), you actually want to treat them as separate
distros.
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.
The more distros we support, the simpler the structure should be.
> > 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). ;-)
As I explained, I only meant to deal with clones, not with somehow compatible
distros. RHEL3 and RHEL4 are so different, that for me it is irrelevant
whether they both come from RedHat or not. And I hate to have to modify the
.pm files with yet another if-then-else and potentially introduce bugs and
breaking working code.
> 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. 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.
> 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.
Regards,
Erich
-------------------------------------------------------
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
