Packaging Google-Daemon

Troy Dawson tdawson at redhat.com
Tue Jun 24 13:52:19 UTC 2014


On 06/24/2014 01:22 AM, Renich Bon Ciric wrote:
> On Mon, Jun 23, 2014 at 7:57 PM, Andy Grimm <agrimm at gmail.com> wrote:
>> I would vote against changing paths here.  /usr/share/google is not
>> that strange.  There are plenty of examples in /usr/share where the
>> next directory is for a collection of packages:  games, man, java,
>> gems, etc.  Deviating from upstream in this case just complicates
>> maintenance of the packages over time.  (If there's some reason the
>> files should not be in /usr/share at all, that's a different
>> conversation.)
> 
> 
> Yeah, you're right. I can think of java doing that and stuff. Besides,
> I do not wanna get into the problem of maintaining my own paths.
> 

Just to check, I looked at my F21 (rawhide) Fedora /usr/share directory.
There are 287 directories in there, and 1 file.  So, the ratio is 287 to
1 in favor of using a directory. :)

Though ... that's not the real reason I was sending this.

I don't want to slow your progress down, but I have on my roadmap plans
to create some RHEL6 and RHEL7 images for GCE.  I'm pretty sure I'll be
able to user your rpm for RHEL7, but just keep in mind that someone will
probrubly come behind you and put your package in EPEL6.
So when you get rid of the init.d files, please do that in the spec
file, and not somewhere before.  That way I'll just have to make changes
to the spec file and not create a new tarball or something like that.

Thank you for all the work you've been doing on this.

Troy




More information about the cloud mailing list