On Fri, Aug 22, 2014 at 5:15 PM, Dusty Mabe <dustymabe@xxxxxxxxx> wrote: > On Fri, Aug 22, 2014 at 02:29:31PM -0600, Orion Poplawski wrote: >> On 08/22/2014 02:23 PM, Dusty Mabe wrote: >> >The scenario I am concerned with here is: >> > >> >if >> > * A requires B >> > * B requires C >> > * C requires A >> > >> >This basically yields a case where ordering can't be properly done because >> >rpm doesn't know which dependency is stronger. If all of the rpms in question >> >just deliver files then all is well with the world but if each of them have >> >scriptlets the ordering can definitely matter and this would be a problem. >> > >> >Dusty >> > >> >> Scriptlet dependency ordering it specified with for example: >> >> Requires(post): pkg >> >> Are there any circular scriptlet deps? > > So that may be the answer. This *new to me* feature solves the case of > scriptlets which is really the only place you see errors *during* the > install. > > Thanks Orion Installation scripting is not the only source of the problem. Perl modules have been prone to this. * Perl module A requires perl module B. * Perl module B requires perl module C. * One small script or macro in module C requires one small script from module A. It may not even be a critical component of C, and may be easily segregated, but suddenly there is a circular dependency. The vortex enters when the author of module B updates to a new dependency or build dependency that is not in the current version of C, and C introduces a new dependency on A but it's based on an older version of A, that has since discarded that macro due to a code cleanup. Hilarity ensues..... The underlying point is that it's sometimes very helpful to split upstream packages to smaller, individual components, precisely to segregate these dependencies. It's especially useful with Perl modules. I have.... old stories about the mod_perl updates back when HTTPD 2.x was first released and mod_perl compatibility became kind of nutty. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
