[fedfs-utils] missing fedfs-utils-server RPM dependency?

[Chuck Lever]

[ This e-mail never appeared on the mailing list when you sent it last month.  Your post was awaiting moderator approval, but the moderator (me) was never notified.  Hopefully I've cleared the backlog of moderator requests now. ]


On Mar 7, 2013, at 2:39 AM, Ian Kent <ikent at redhat.com> wrote:

> On Tue, 2013-02-12 at 13:03 -0500, Chuck Lever wrote:
>> Hi Ian-
> 
> Sincere apologies for not checking the mailing list sooner.
> 
>> 
>> I installed the fedfs-utils-server RPM and discovered that it does not
>> pull in fedfs-utils-lib.  Should it?  Or do I misunderstand the intent
>> of fedfs-utils-server?  Is that for installing only rpc.fedfsd?
> 
> I guess that makes sense but AFAICS rpc.fedfsd doesn't actually depend
> on it. I can add it as a dependency if you believe it's needed?
> 
> There's a bigger issue though and that is the break down of packages.
> You asked if we could have fedfs-utils install the cluster of
> sub-packages for simplicity. 
> 
> That is a good idea IMHO but while working on bug 889174 I noticed that
> to do that we would need to make the base package depend on almost all
> the sub-packages. The packaging guidelines specifically say if that's
> the case then the need for sub-packages should be re-considered.
> 
> Some packages seem to have got away with creating a separate
> meta-package which depends on all or most of the packages in the
> cluster. I don't know how the maintainers got that by the packaging
> committee and I don't really think it's a good idea for us to try.

My expectation was set by 389-ds, which has a base package that installs a bunch of other packages.  If that is an exception rather than a rule, so be it.

> Given the changes for bug 889174 have only recently been done it's
> probably not a good time to make such a fundamental packaging change.
> It's probably best done at the next source version update.
> 
> Thoughts?

I don't have any reason for wanting to install all the packages together except for convenience when testing.  If it's going to be less pain for everyone involved to have a single package, then let's consider that for fedfs-utils 0.10; otherwise, I promise not to mention it again :-)

> 
>> 
>> Also, if you're already mucking about in the SPEC file to address
>> bugzilla 889174, could you update the Source URL to point to the
>> correct tarball location:
>> 
>>  http://git.linux-nfs.org/?p=cel/fedfs-releases.git;a=summary
> 
> Yeah, the git URL is a bit unwieldy, it's huge.

I didn't realize there was a limit.  Is it really that much of a problem?  I kind of like the idea of having the package checksum embedded in the URL.

Meanwhile, the oss.oracle.com location is never going to be updated past 0.7.4.

> How about we find a home for the tarballs, like kernel.org, somewhere
> near the location of autofs seems sensible to me?
> 
> I can contact kernel.org support and request it and upload the tarballs
> if you wish.

I'll think about that.  I would want to get a kernel.org account so I can publish these when they are released.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com