Well, I'm certainly a fan. Now, we just need some upstream traction.
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. For more options, visit https://groups.google.com/d/optout.
