[Fedora-directory-users] Request For Comment: fedora-ds-utils project

[Ken Marsh]

Chris,

As someone currently looking for some of these scripts, I think this is
a great idea. I'll throw in a few comments.

> 2. The program must include 'ds' as the first element in the
> name; for
>    instance:
>
>    - ds-mmrtool
>    - ds-schema-migrate
>    - ds-setup-ssl 
While I like the consistancy, this sort of introduces a massive
documentation bug. People will read the Red Hat DS or 7.1 DS or latest
DS documentation, look for (say) setup-ds-admin.pl, and it will be
missing (renamed), and come right back to the mailing list asking for it
again.

> 4. The program must ONLY produce output a) on errors; or b) with the
> -v
>    flag.  In the event of successful operation, no output should be
>    produced at all. 
I suspect the purpose of some scripts is to produce output. Also, some
scripts call other perl or shell scripts, and tying up all those outputs
neatly would probably involve rewriting them all.

> 5. The program must be capable of running completely unattended.
Yes!

7. All dependencies of the program must be available as RPMs in the
   current release of Fedora Linux

OK, but hey! Don't forget us Red Hat (paying) customers. I've had many a
cool new package refuse to run on Enterprise 4 because supporting
packages were "too old" or packages weren't available. I can understand
giving up on Enterprise 3, but right now E4 is still the massive user
base.

 
Ken Marsh

[Chris St. Pierre]

Ken--

Thanks for your comments.  Some counterpoints below. :)

>  While I like the consistancy, this sort of introduces a massive
>  documentation bug. People will read the Red Hat DS or 7.1 DS or latest
>  DS documentation, look for (say) setup-ds-admin.pl, and it will be
>  missing (renamed), and come right back to the mailing list asking for it
>  again. 
Most of the scripts I'll be working with won't be mentioned in the
official Redhat documentation; they're peripherals, not central to the
operation of the DS.  (E.g., setup-ds-admin.pl -- which _has_ been
renamed, incidentally -- is packaged in fedora-ds-base itself.)

That said, it might be a reasonable compromise to create a package
that installs a script, say, ds-schema-migrate, plus a symlink to that
script from ol-schema-migrate.pl, but make the script generate a
warning when it's called by the old name.  This should make it
possible to change the existing documentation -- mostly on the Fedora
DS wiki, I believe -- referring to those scripts at our leisure, while
not breaking old functionality.  Thoughts?

>  I suspect the purpose of some scripts is to produce output. 
Heh, good point.  I'll have to write that requirement a little more
carefully.

>  Also, some scripts call other perl or shell scripts, and tying up
>  all those outputs neatly would probably involve rewriting them all. 
I'm still not deterred.  If the programmer calls a command that
generates unwanted output, it should be the job of the programmer --
not of the sysadmin -- to handle that output gracefully.

>  OK, but hey! Don't forget us Red Hat (paying) customers. I've
> had many a
>  cool new package refuse to run on Enterprise 4 because supporting
>  packages were "too old" or packages weren't available. I can understand
>  giving up on Enterprise 3, but right now E4 is still the massive user
>  base. 
I actually _am_ one of those paying customers, so I feel your pain. :)
That said, Fedora DS is a Fedora project, and while it'd be nice to
only allow RHEL dependencies, I don't think it's reasonable for a
Fedora-related project to tie itself to that (slower) release cycle.

In practice, this is really only a problem where a package requires a
_newer_ version of something than is available for RHEL X.Y; I've
rarely run into a package available for Fedora that isn't available,
prebuilt, for RHEL, whether from Dag Wieers, EPEL, CentOS Extras, or
any of the other third-party repos out there.

I'll add some language stating that scripts _should_ endeavor to work
on all currently supported RHEL releases, but I don't think we can
make this a requirement.

Thanks again!  Great input!

Chris St. Pierre
Unix Systems Administrator
Nebraska Wesleyan University