[Opendnssec-user] Re: Summary of the RPM subject
Rachid Zarouali
rzarouali at gmail.com
Thu May 27 10:20:39 UTC 2010
hy all,
@Ville: thanks for pushing into gitorious, we now have some fuel to
deal with :-)
@Tim: if we can use CentOS build factory until we have our own koji
running, that would be perfect !
regarding directory naming, i will write a draft on this and will
publish it here so we can discuss and decide how to manage branches
and directories.
i haven't taken a deeper look on pushes you've made ville, but i'll
try to take a closer look this week-end.
they are few other things that need to be settle down:
- QA on our rpms
- some quick rules on how to maintain rpms and spec following the
evolution of opendnssec and softhsm.
- packaging policy to have chances to see our rpms inclued in major RPM Distro.
besides sqlite is not the only package in which we must be carefull
dnsruby and rubygem as well.
at first i've packaged them into quick and dirty rpms.
should we work on package them regarding QA rules from EPEL and/or
CentOS community ?
i've seen very usefull informations on rpms QA on the CentOS wiki and
fedoraproject website.
btw, Tim did you manage to create a gitorious account, as far as i
remember i haven't seen it yet following rpmodssec.
Rachid
On Wed, May 26, 2010 at 8:58 PM, Ville Mattila <vmattila at csc.fi> wrote:
> Hi,
>
> On Wed, 26 May 2010, Tim Verhoeven wrote:
>
>> Sorry for the delay. It's been busy at work. Anyway, for the sqlite
>> package. The best method to use is (and the one used at the CentOS
>> project) is to create a separate package somewhat like the compat
>> packages used to keep older libraries available. But in this case we
>> will use it for a newer library.
>
> True. There must be some common practices on how to package the compat
> libraries and how to link against them?
>
>> Then we need to get OpenDNSSEC and SoftHSM to compile using this
>> library. I don't like to use things like LD_LIBRARY_PATH or any other
>> tricks. We should be able to just point it to the right sqlite
>> package/location. If necesarry we need to make changes to the
>> configure/make scripts.
>
> I agree 100% that easy to maintain solutions are best and thus I
> certainly do not like the LD_LIBRARY_PATH wrapper trick I've implemented
> for opendnssec-1.1.0-0.1.rc3 (which I committed just yesterday to
> rpmodssec-dev/gitorious).
>
> However, how do you actually point OpenDNSSEC the right sqlite location
> without LD_LIBRARY_PATH etc? Add the directory of sqlite
> libraries into RPATH of the ELF binaries with e.g. chrpath tool?
> Are there other possibilities?
>
>> For the build infrastructure. We can use the CentOS build machines,
>> meaning that I can submit packages to the CentOS devel repo and they
>> get build automatically and become available on the internet. This is
>> a also a good test to make sure the packages build cleanly inside a
>> chroot.
>>
>> So, what SPEC files and/or src.rpms are already out there ? If OK I
>> can merge them all together and we can all start working from there ?
>> I think I already mentioned that my primary focus would be for 1.1.
>> Once that is ready we can look at 1.0 packages.
>
> Please do merge. My current spec files and patches are available at
> http://gitorious.org/rpmodssec/rpmodssec-dev/trees/master
> (though I probably should've chosen another branch name but then
> again it was the very first time tried using git).
>
> The v1.1 spec file (at gitorious) includes all the fixes I had in my v1.0
> packages which had sqlite statically linked; The v1.0 specs and packages
> are still available at http://staff.csc.fi/vmattila/software/packages/el5/
> but be warned that the tricks for building and linking the sqlite prior
> to OpenDNSSEC itself "are not for the faint of heart".
>
> BTW, if you use stuff from my spec files please note there are some
> patches adopted directly from Ondřej Surý's Debian/Ubuntu packages
> and the opendnssec-sqlite package is based on Fedora 12's sqlite
> and this should probably be noted in credits etc. at least.
>
> Regards,
> Ville
More information about the Opendnssec-user
mailing list