Packaging Google-Daemon

Troy Dawson tdawson at redhat.com
Tue Jun 24 14:02:27 UTC 2014


On 06/24/2014 08:52 AM, Troy Dawson wrote:
> 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
> 

Of course, after I send this I see your emails with links to your src.rpm.
Looks good to me, and thanks for all your efforts.
Troy




More information about the cloud mailing list