[openstack-dev] [heat] Future of the cfn-tools

Zane Bitter zbitter at redhat.com
Fri Jan 25 19:28:33 UTC 2013


On 25/01/13 19:42, Thomas Goirand wrote:
> On 01/24/2013 11:28 PM, Zane Bitter wrote:
>> There is one known issue that anybody wanting to package
>> aws-cfn-bootstrap in a distro would have to circumvent: the current
>> tools are installed (appropriately) in /opt/aws/bin.
>
> This is all but appropriate ...

I think it was entirely appropriate for AWS to put them in /opt when 
they were supplying them as a third party and not part of the distro. 
Obviously it would have been better for everyone had they packaged them 
in upstream distros instead, but apparently the code was not Open Source 
in the OSI sense at that time.

Packaging them in /opt in a distro would obviously be completely 
inappropriate.
>
>> Amazon, through
>> their example templates, have encouraged people to use the
>> fully-qualified path (e.g. /opt/aws/bin/cfn-init) when calling them,
>> instead of just adding /opt/aws/bin to $PATH.
>
> Stupid example, if you ask me.

It's highly unfortunate, and I'm guessing happened because the 
transition to Open Sourcing the code was probably not planned at the 
beginning.
>
>> The latter would have made
>> the transition to including the tools in the distro (where packaging in
>> /opt is *not* appropriate) transparent, but the former most certainly
>> does not. I have several ideas for working around this, none of them
>> good ;)
>
> I have discussed this with upstream authors of Heat, when they showed me
> the package. For a distro like Debian, packaging anything in /opt is a
> no-go. This goes against the FSHS.

[A note for those who haven't been following Heat closely - Thomas is 
referring to Heat's current cfn-tools package here.]
>
> Though, one thing that could be done is a userland script (that would be
> called on the command line explicitly by the users, eg *not* by a
> postinst script or the like) that would create some symlinks in /opt in
> order to get the compatibility. This would be compliant with the Debian
> policy manual, IMO.

Yes, I think that is the way to go. Good to hear that this would be 
considered compliant for Debian. Thanks for your input :)

cheers,
Zane.



More information about the OpenStack-dev mailing list