This is more of a discussion about how openpkg tools find dependencies and thus rebuilds and/or installs rpms. It appears that if something is listed as a BuildPreReq or as a PreReq, then it will want to rebuild and/or install the rpm. There is a subtle problem with this, I think. I'm thinking that openpkg tools should only rebuild the rpms if it is listed under BuildPreReq and not worry about the PreReq. It should, of course, worry about the PreReq when checking to see if that rpm is installed or not, but that's it. BuildPreReq would ideally be used to state what other libraries or software needs to exist during (re)build of a given package. PreReq would list the various software that needs to be installed during install time in order for the software to even function properly. These two things can be different and ultimately, probably should be different in most cases. Now, don't get me wrong. I realize this would require some serious accountability and attention to detail. I'm just curious if it would be possible to modify openpkg tools so that it only rebuilds and installs dependent rpms if it in the BuildPreReq but not in the PreReq.
Let me explain the dilemma so that it is (hopefully) understood. I will use an example using the latest sendmail security fix. When the fix is released, obviously, sendmail needs to be rebuilt and deployed. In addition to rebuilding sendmail, openpkg tools sees various other rpms as also needing to be rebuilt then reinstalled due to static library linking. For our environment, this includes: dk-milter; imapd; inn; mailman; majordomo; mapson; mimedefang; nagios; nail; nn; pine; pks; qpoper; pb4sd; and, shiela. Now this isn't that many really, but how many of these actually need to be rebuilt and reinstalled? I don't think any of them need to be rebuilt actually. I'm pretty sure none of these dependent rpms are build with statically linked sendmail libraries. So, why is this a problem? Of these rpms six of them are used as part of critical (i.e. high availability) services. When these are reinstalled there is a subtle, yet noticeable by many, blip in the radar. There may even be in some rare instances a complete failure of the service because it doesn't restart properly or something of that nature. Obviously, in any critical service environment, this presents a problem. Now, as for the solution, I can foresee a couple things to do. One is that some standards need to be written on how to write spec files. Within this standard document for writing spec files it should be indicated that BuildPreReq and PreReq have the two different aforementioned definitions for very specific reasons. This, of course, is only one piece. The other piece is going to be that we have to go through all of the current spec files and evaluate if the various BuildPreReq and PreReq values are defined in the manner we decide. (By "we" I mean the OpenPKG foundation and by "decide" I mean that I am not stating how it should be done only possible ways it could be done and thus a decision needs to be made.) In addition, the openpkg-tools will need some reworking. How much I don't know. Maybe it's just a small tweak or maybe it's a major undertaking. That will have to be figured out (unless it's already known) then the time to do it will have to be determined. That's the tough part...time. Time is our nemesis! We should've never made that up. ;-) In any case, what say you all? Thoughts/ideas? -- David M. Fetter - Portland State University - UNIX Systems Administrator "Reality is merely an illusion, albeit a very persistent one." ~Einstein
signature.asc
Description: This is a digitally signed message part
