Good comments. Exactly what I was looking for.
Do you see value in going at it with the person who wrote that spec file
(I know he has quite a bit of experience writing spec files, but is
probably less familiar with the issues you bring up here) to come to
common ground? If not, and you're satisfied where the spec file is now,
that's fine too.
If you'd like to chat with him about it, his name is Michael Jennings (Eterm guy) and you can reach him at: [EMAIL PROTECTED]
If you decide not to, then let's go ahead and go for rpmizing the 3.2.2 release.
Cheers!
-Brian
Thus spake Jerry G. DeLapp ([EMAIL PROTECTED]):
You should be wary of asking me for an opinion... 8 paragraphs to follow ;-).
I've been disturbed for some time by the incompatibilities of the si RPM install with the various distros. For example, si-server clobbers /etc/xinetd.d/rsync... but what if the admin is like me and has changed the xinetd.d config file to specifically run with systemimager's rsyncd.conf?
This spec flie goes further down that road in that it assumes that the default place for the rsync_stubs directory is the only possible place. That is, it ignores the content of the systemimager.conf file, which is capable of relocation of the input directories of mkrsyncd_conf. It further compounds that by going on to write 'replacement' stub files in what it presumes to be the right place. Again, I actually *do* change the content of systemimager.conf, my /etc/systemimager/rsync_stubs dir is empty, and I like it that way ;-).
In my own situation, I'd consider this behavior wrong even if it did respect the systemimager.conf file, because it would do the wrong thing for 'non systemimager' rsync items (things that would go in a nnlocal stub). It would also do the wrong thing if an image line had a trailing blank on the end of it.
This is akin to the recent bug report where the user wishes us to run chkconfig 'on' for netbootmond and rsyncd as the default behavior for the rpm. I'd vote no on that, too, because the *first* thing I do after an rpm install is to remove /etc/init.d/systemimager-* and go back and repair the damage to the xinetd.d directory. I also consider this specfile, although it improves in that area, to be doing the wrong thing. I, for example, would prefer that the server rpm 'notice' whether or not xinetd was installed, and would just edit the xinetd.d configuration. This behavior would be arguably "wrong" for debian or rh7, though.
So, I've deliberately avoided making new modifications to the pre and post install scriptlets because I have been very wary of making these (what I consider to be) inappropriate behaviors change further, which is what I think this specfile does. I think the current behavior is wrong, but at least I know how to get unfouled after an RPM install. I'm a big fan of 'first, do no harm' as the default behavior. If that means that you do nothing automatic during RPM installation, so be it. My outlook is strongly colored by the fact that I know what si is doing under the hood, I heavily customize its behavior, I need my rsync server to do more than si, and I know where to find the configuration files. So, I'd actually prefer to see the pre and post install scriptlets be less harmful by either killing them completely, or making them understand, even more fully than this example does, what they are modifying.
I'm willing to be convinced otherwise. But, right now, I'd much rather see this 'how do I get configured, upgraded from [23].0.x, converted from init.d to xinetd.d, etc" problem addressed with better documentation (wiki) and/or in scripts that go in the doc directory. Those could be run at the admin's discretion, or used as examples of the work that needs to be done to 'finish' a configuration.
Other than that, the file appears to be well written with liberal and consistent use of the undocumented rpm macros. I've written many spec files that use the same double underscore style macros for my own 'personal' RPMs. I get nervous, however, about using anything starting with double underscore in a file for public consumption. I've always adhered to the convention that __ means 'private'. That is, I have concerns that redhat or fedora or debian would change the content or meaning of those macros if it suited them, because they are not published in any public specification that I know of. I might be wrong about that though. If I am, then I'd certainly vote for doing the build internals in this style.
Ditto the above sentiments for the fact that this spec file uses bash specific syntax. I don't know if there is a specification someplace that affirms that the default rpm shell is bash and not 'just sh'? I've never seen any other specfile that uses the [[ ]] bash syntax.
On Tuesday 13 April 2004 17:53, Brian Elliott Finley wrote:One more try, with the attachment...
Thus spake Brian Elliott Finley ([EMAIL PROTECTED]): >Michael's update attached... > >I'd be curious to see what you think. And his source rpm can be found >here: > > http://caos.nplus1.net/~mej/systemimager-3.2.2-1.src.rpm > >Please combine your spec file and his as you see fit. > >Cheers, -Brian > >Thus spake Brian Elliott Finley ([EMAIL PROTECTED]): >>Jerry, >> >>Michael Jennings is sending me some spec file updates he's recommending. >>I'll pass them along for your review soon as I receive them. Let's not >>worry about building the RPMs until we get those updates -- apparently >>Michael is rpmizing 3.2.2 as we speak, for the http://www.caosity.org/ >>distribution, so we should have them plenty soon. >> >>Cheers, -Brian >> >> >>-- >>--------------------------------------------------------- >>Brian Elliott Finley Argonne, MCS Division >>Phone: 630.631.6621 http://thefinleys.com >>gpg --keyserver wwwkeys.pgp.net --recv-keys 10F8EE52 >>--------------------------------------------------------- >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: IBM Linux Tutorials >>Free Linux tutorial presented by Daniel Robbins, President and CEO of >>GenToo technologies. Learn everything from fundamentals to system >>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >>_______________________________________________ >>Sisuite-devel mailing list >>[EMAIL PROTECTED] >>https://lists.sourceforge.net/lists/listinfo/sisuite-devel > >-- >--------------------------------------------------------- >Brian Elliott Finley Argonne, MCS Division >Phone: 630.631.6621 http://thefinleys.com >gpg --keyserver wwwkeys.pgp.net --recv-keys 10F8EE52 >---------------------------------------------------------
--
---------------------------------------------------------
Brian Elliott Finley Argonne, MCS Division Phone: 630.631.6621 http://thefinleys.com
gpg --keyserver wwwkeys.pgp.net --recv-keys 10F8EE52
---------------------------------------------------------
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Sisuite-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
