On Mon, Mar 10, 2014 at 1:36 PM, Trevor Vaughan <tvaug...@onyxpoint.com>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
> <drew.bless...@buckle.com>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 <drew.b...@buckle.com>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
>>>>> <drew.b...@buckle.com>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 <adr...@puppetlabs.com>
>>>>>>> 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 puppet-dev+...@googlegroups.com.
>>>>>> 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 puppet-dev+...@googlegroups.com.
>>>> 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
>>> tvau...@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/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
> 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%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
a...@puppetlabs.com
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 puppet-dev+unsubscr...@googlegroups.com.
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.
