Well, I can see these solutions here:
1. Release rpms for RH-7.3 and put those patches there. Or may be put
the patches under 'legacy' dir in libbash/xconfig distribution.
Considering amount of related changes and xconfig/libbash release
cycle, it does not look like time-consuming task to maintain it.
Pros: Easy, minimal initial time investment.
Contras: Not elegant - manual patches track. Becomes more difficult to
maintain as amount of differences grows.
2. Create libbash-compat and xconfig-compat branches in version
control system. This means releasing two sets of tarballs and rpms.
This solution is much like the first one, but more elegant.
Pros: Version control does everything. Very elegant.
Contras: Two release sets - users will somehow have to choose which
one is relevant for them.
3. Just like 2, but release one single tarball, which will have both
new and old code sets and master configure-like script which will test
the system and then pass control to either new or compat version.
Pros: Like in 2
Contras: Alghouth 2.contras is eliminated, but new contras are
* configure-like script have to be maintained to contain
all relevant system checks
* We still will have to release original new and compat
tarballs, since distribution vendors will want them and not this new
all-in-one tarball.
* So by saving user from some thinking we introduce
another type of release file.
4. Move to templates, that will be substituted by configure. For
example @sed_tab@ will be expanded either by '\t' of by ' '
depending on sed version.
Pros: Single code line and release set
Contras: Very time consuming. In fact, we'll start to implement our
own set of macros, which will have to be extended each time another
backward-incompatibility is discovered. Each xconfig/libbash developer
will have to become familiar with this macro set.
5. Write backward compatible code. But this is just ugly...
Start voting guys! :)
I'm voting with both hands for solution number 2!
On 8/14/06, Dick Marinus <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've started hacking libbash and xconfig to make both scripts compatible
> with bash 2 and older coreutils (I'm stuck to a Red Hat 7.3 environment)
> Please review my patches attached to this mail.
> I think it would be a good idea to use autoconf / automake to detect the
> bash version and generate the scripts with appropriate code. Could
> someone please give me some hints about this?
>
> Thanks in advance,
> Dick
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Xconfig-common mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xconfig-common
>
>
>
>
--
Zaar
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Xconfig-common mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xconfig-common
