On Mon, Mar 10, 2014 at 1:36 PM, Trevor Vaughan <[email protected]>wrote:
> Well, I'm certainly a fan. > > Personally, I would be ok with yet another hack in puppet 3 to handle this issue since it has been coming up so often and since I also don't know a clear timeline for getting new functionality in to address this specific issue in a better way. And yes, my idealism is cracking :/ An advantage of getting a specific fix in for this is that it would clearly point out where the RAL needs for flexibility than it has right now. I think we all have an idea of where it needs it in general, but some of the nitty gritty details would be nice. > Now, we just need some upstream traction. > > A patch that achieves what is being talked about here just needs to be submitted :) > > On Mon, Mar 10, 2014 at 4:29 PM, Drew Blessing > <[email protected]>wrote: > >> I think that sounds like a great way to approach the issue, Trevor. >> Adrien, what do you think? >> >> FWIW, I just encountered this issue for the second time in a week. I >> suspect this trend will continue. We are finally getting comfortable with >> custom types/providers and want to build providers to interact with APIs. >> If we control the package then we can shift things around easily but in >> many cases we control neither the gem nor the rpm package. >> >> >> On Monday, March 10, 2014 1:28:49 PM UTC-5, Trevor Vaughan wrote: >> >>> It's just this one, as far as I know. >>> >>> I would like to see the RAL updated, but I'd like this fix in Puppet 3 >>> and the RAL update in Puppet 4/5/whatever. >>> >>> Trevor >>> >>> >>> On Mon, Mar 10, 2014 at 11:15 AM, Drew Blessing <[email protected]>wrote: >>> >>>> Unless you can definitively say that making major changes in the RAL >>>> to address this issue is slated for the near future (say, late 3.x release >>>> or first 4.x release), I'd say the individual fix for package type is >>>> warranted in the meantime. Are there any other types that you think people >>>> are having major issues with at the moment? Maybe the "shim" could be >>>> released in 3.x series and work can proceed on the longterm fix in the 4.x >>>> series? >>>> >>>> >>>> On Monday, March 10, 2014 10:07:42 AM UTC-5, Adrien Thebo wrote: >>>> >>>>> My concern with this solution is that it's a one time shim for a >>>>> single type. Granted, it may work and could solve this particular problem. >>>>> However I think this is a flaw in the RAL that has a number of touch >>>>> points >>>>> that also need to be fixed. This might be me being too idealistic but I >>>>> think that we can fix this issue and improve the entire RAL rather than >>>>> trying to make individual cases work as expected. >>>>> >>>>> >>>>> On Mon, Mar 10, 2014 at 6:09 AM, Drew Blessing >>>>> <[email protected]>wrote: >>>>> >>>>>> I agree, it seems like this solution would be simple and effective. I >>>>>> am almost positive there are other types that behave this way. It breaks >>>>>> nothing and fixes everything, as far as I can see. >>>>>> >>>>>> On Saturday, March 8, 2014 2:48:21 PM UTC-6, Pedro Côrte-Real wrote: >>>>>> >>>>>>> On Fri, Mar 7, 2014 at 10:15 PM, Adrien Thebo <[email protected]> >>>>>>> wrote: >>>>>>> > Long story short, allowing multiple resources to exist with the >>>>>>> same title >>>>>>> > but different providers is problematic. >>>>>>> >>>>>>> There's no reason to need to do that though. Package just needs to >>>>>>> be >>>>>>> able to override the package name without changing $name as that >>>>>>> needs >>>>>>> to be unique. So you should be able to do something like: >>>>>>> >>>>>>> package { 'somepackage-in-apt': ensure => present, pkgname => >>>>>>> 'somepackage', provider => apt, } package { 'somepackage-in-gem': >>>>>>> ensure => absent, pkgname => 'somepackage', provider => gem, } >>>>>>> >>>>>>> Since we've used $pkgname instead of $name this doesn't have the >>>>>>> uniqueness issue. I've looked around the code and this seems easy >>>>>>> enough to do. The Package providers just need to do "pkgname ||= >>>>>>> name" >>>>>>> so the older stuff doesn't break. >>>>>>> >>>>>>> Can anyone find any fault with this solution? I've commented on >>>>>>> these >>>>>>> bug reports a lot of times and never gotten any answer to this. It >>>>>>> seems pretty amazing that this bug still exists after so many years. >>>>>>> >>>>>>> Pedro >>>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>>> msgid/puppet-dev/7eb053d7-be1b-47b0-8a72-73a57d898612%40googl >>>>>> egroups.com<https://groups.google.com/d/msgid/puppet-dev/7eb053d7-be1b-47b0-8a72-73a57d898612%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Adrien Thebo | Puppet Labs >>>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/puppet-dev/74d181f4-60ed-40d3-bcb8-84cc3543d862% >>>> 40googlegroups.com<https://groups.google.com/d/msgid/puppet-dev/74d181f4-60ed-40d3-bcb8-84cc3543d862%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 >>> [email protected] >>> >>> >>> -- 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/15b633d6-9713-4d94-8210-b202447e02c9%40googlegroups.com<https://groups.google.com/d/msgid/puppet-dev/15b633d6-9713-4d94-8210-b202447e02c9%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 > [email protected] > > > -- 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoV0g7gj5d__c-24DRJVcryszZNbARLKBiBH83KrKs4LEg%40mail.gmail.com<https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoV0g7gj5d__c-24DRJVcryszZNbARLKBiBH83KrKs4LEg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco - * http://bit.ly/pupconf14 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANhgQXsO-THztZT6G91qQCx0Oh8t9-V-HD_8zDjGPnKY%3DxcENQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
