On 2/17/2010 9:35 PM, Steven Dake wrote:
> On Wed, 2010-02-17 at 22:21 +1100, Angus Salkeld wrote:
>> On Wed, 2010-02-17 at 07:47 +0100, Fabio M. Di Nitto wrote:
>>> I only have a few comments, some of them we discussed on IRC.
>>>
>>> When adding new files, you need to update the corosync.spec.in too.
>>> In general my policy has always been that (s)rpm from development should
>>> enable all features and ships all files.
>>>
>>> Since those files are useful only when augtool are available, I suggest
>>> you create a separate binary rpm to ship them (call it corosync-augeas
>>> for example) that will Requires: augeas as dependency.
>>>
>>> This way, it´s clear what those files do, they don´t interfere with
>>> normal packaging, and they become optionally installable even in testing.
>>>
>>> Fabio
>>>
>>
>> Here is a patch that should do the trick.
>>
>
> According to augeas upstream, separate rpms are not recommended unless
> there is a dependency on augtool or library.
The dependency is there.
> The issue with this spec file patch is that it creates unowned dirs
> (+%{_datadir}/augeas/lenses). Some distros (fedora) own these dirs in
> the "filesystem" package. It is not clear to me that other distros will
> do that, and instead choose to own them in the augeas packages (in which
> case a dependency on augeas makes since, so that it can own the proper
> dirs).
A problem that´s very easily solvable. Simply own the dirs you create.
It´s allowed to have multiple owners for one dir.
> [r...@fedora12-node1 cluster]# rpm -q -f /usr/share/augeas/lenses
> filesystem-2.4.30-2.fc12.i686
> augeas-libs-0.7.0-1.fc12.i686
filesystem doesn´t own it alone (augeas pulls in -libs as suggested by
upstream)
> It is not possible to predict what adoptors of augeas will do with
> regard to the lens dir owning issue.
Remember that this spec file is for developers only and not for general
distributions. Each distribution will always add little changes here and
there to fit the distro specific policy.
If the rpm can´t fit all distro, then distro people can happily send us
patches to fit their specific policies. So far we work and develop on
Fedora.. we fit those policies.
IMHO you are creating a problem that really isn´t necessary.
Also note.. if you want to go into distro specific policies, then you
probably want to review the whole spec file idea. Probably even the
./configure call is not right on all distros (some enforces usage of
/etc/init.d and others /etc/rc.d/init.d even if the two are hardlinked
together, only one is the correct for packaging policies).
Fabio
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
