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