Well, there's my concrete example of where dangling symlinks are used in the wild....
Ok, back to autorequires. I'm still not convinced that it's beneficial to not have it in place. I suppose that I could do some hack-fu like I did with 'group' so that people that want it could patch it into place but that seems a bit unfortunate. Are auto* items things that should be allowed to be disabled on a resource-by-resource basis using a Metaparameter? That way you can do the 'usual' thing but, should it cause an issue, just turn it off for that resource and declare things explicitly. I'd much rather be able to shim in my own auto* items from the DSL (I mean, it's an Array), but this goes back to the 'if defined considered harmful' argument which, in turn, spawns John's "Puppet's not my Nanny" argument. Good conversation and idea flow throughout! Thanks, Trevor On Mon, Mar 2, 2015 at 1:29 PM, Reid Vandewiele <r...@puppetlabs.com> wrote: > On Monday, March 2, 2015 at 7:21:55 AM UTC-8, Trevor Vaughan wrote: >> >> Hmm....Ok, how about this: >> >> 1) Dangling symlinks are allowed >> 2) Warnings on dangling symlinks are the default (because you *probably* >> don't want them) >> 3) Setting :force => true, disables the warning message (in theory, you >> would only do this after seeing the message) >> > 3a) For a less destructive method, something like 'dangle => true' could >> be allowed I suppose >> 4) Autorequires happen so that you don't get spurious warning messages >> >> Would that work? >> > > It still seems presumptuous to me even to emit warnings by default if > Puppet creates a symlink which is dangling at the time of creation. The > assumption is that potential benefit of the alert would outweigh the cost > of the potential noise and extra parameters required to silence it when > dangling symlinks are desired. > > Besides the crazy things symlinks get used for on occasion, such as Samba's > use of dangling symlinks to represent DFS file shares > <https://wiki.samba.org/index.php/DFS>, Puppet may legitimately be asked > to create a link prior to installing a package or performing another action > which will result in the target being created, and users shouldn't need to > set :force or :dangle for their first run to log cleanly. > > The potential benefit of the noise does not merit the extra complexity to > silence it. This is an instance where Puppet cannot reasonably determine > whether or not a dangling symlink is a problem and should not presume to do > so. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/1f9719c7-3729-4311-b93f-c386408f1e6d%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/1f9719c7-3729-4311-b93f-c386408f1e6d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoV4MEKDrF-btfjdGzYVEFQDKpQ1j3%3D7364fgc76rivGSQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
