Inclusion of Ingres RDBMS in Fedora

Tue Feb 23 16:34:49 UTC 2010

On 2/22/10 9:33 PM, Iain Arnell wrote:
> On Tue, Feb 23, 2010 at 4:09 AM, Jay Hankinson
> <jeremy.hankinson at ingres.com>  wrote:
>    
>> Hello Fedora Devs,
>>      
> Hello Ingres Dev,
>
>    
>> Over the last few weeks, I spent a lot of time review and amending the
>> Ingres (a highly scalable, full-featured open source RDBMS) building and
>> packaging process with the intention of submitting it for inclusion in
>> the Fedora distribution. We've had binary RPM support for a while but
>> was far from being LSB compliant and violated other packaging standards.
>>
>> The focus of the work has largely been based on information found at:
>>
>> https://fedoraproject.org/wiki/Packaging/Guidelines
>> https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
>> &
>> http://proton.pathname.com/fhs/
>>      
> You'll also want to check http://fedoraproject.org/wiki/Packaging_tricks
>
>    
Thanks
>> and I am now at a point where I can build 3 binary RPMs (ingres-client,
>> ingres-server, ingres-devel) which comply with the above guidelines and
>> which cause rpmlint to return very few errors.
>>      
> Ugh! They're a necessary evil at times (I've done a few of my own),
> but since you have the source and intend to build source-based RPMs
> anyway, it's almost always better to dive straight in and simply start
> building RPMs from source. On the positive side, though, it's still a
> learning experience: you know it's possible, what files need to go
> where, etc.
>    
There were a number of changes I needed to make wrt to where Ingres 
reads and writes files and to the way the setup procedure runs in order 
to satisfy FHS. It was easier to use the existing binary RPM building 
mechanisms to do this, rather than changing everthing at ones and trying 
to workout what broke what. And yes, I learned a lot in the process ;-)
>    
>> However, one major thing
>> that is still missing is the ability to build an SRPM for the source
>> tree and crafting an SPEC file for this is the next thing on my task
>> list. As I think this will be a fairly substantial undertaking and
>> something I'm not very familiar with, I'm keen to get some advice and
>> guidance with the project in the hopes of getting things done right (or
>> at least more right) the first time.
>>      
> It's not really that hard. In fact, if you can change the build
> process, it may be easier than making the binary RPMs. In an ideal
> world, the existing configure/compile/install process should handle
> all the hard work; if it doesn't, hopefully you can change it so that
> it does. Otherwise, you should be able to configure/compile/install
> using the existing process and move the installed files around as you
> do for your existing binary RPMs.
>
>    
>> Also, there are a few issues that
>> have arisen from building the binary RPMs that I would like to get
>> clarification (i.e. how much of a problem are they) on before starting
>> on the SRPM spec:
>>
>>      * Ingres requires that the server executable is setuid (non-root)
>>      
> That shouldn't be a problem; rpmlint may complain, but
> %attr(4755,ingres,ingres) /usr/bin/ingres (or whatever) in %files list
> is okay. But is it really necessary? Non-root daemons are normally
> started by root user anyway using initscripts and can use
> /sbin/runuser to start the daemon as the appropriate user.
>    
The issue isn't starting the server (runuser is used). All the data in 
Ingres databases is owned by the ingres user in 700 directories. In 
order to perform backups (checkpoints in Ingres speak) as DBA users 
other than ingres, the server executable (which performs the checkpoints 
under a different name) needs to be setuid to access the data. Doesn't 
sound like it's a problem though, cool.
>    
>>      * Current build process uses $ORIGIN for relative RPATH linking.
>>      
> This one is slightly trickier. Using rpath for system libraries is
> absolutely forbidden. But packaging guidelines has information for
> removing rpath, and packaging tricks link (above) suggests that rpath
> may be used for internal libraries.
>    
I can probably work around this, we don't use it for system libraries 
only our own shared libraries. I was wondering though, as $ORIGIN is far 
more secure than absolute rpath linking that it might be an allowable 
alternative to ldconfig additions. Or is that a hard and fast 
requirement too.
>    
>>      * Executable stack code
>>      
> Maybe it doesn't need this [1].
>    
Yes, I'd seen that post on our forums, there was a QA issue about it 
too. I think it probably a hangover from our own internal threading 
implementation from the days before pthread. I was just curious as to 
how much of an issue it was going to be. Haveing looked into it some 
more, I think you're right, it doesn't need to be there.
>    
>> If the best approach is "write the spec, follow the guidelines, create a
>> Bugzilla issue and we'll go from there", then that is what I will do. If
>> I can gain experience by assisting in with the packaging of other
>> software for fedora then I'm happy to do this too.
>>      
> That's pretty much the way to go. Fedora package review is usually an
> iterative process anyway. I think its better to start early and get
> feedback right from the start.
>    
Great, then that's what I'll do.
>    
>> If this is the wrong list for this posting, apologies and please direct
>> me to the appropriate forum.
>>      
> Nope, this is absolutely the right place. Welcome!
>    
Thank you. Your help is greatly appreciated.
> [1] http://community.ingres.com/forum/dba-forum/11683-fedora-12-64bit-selinux-doesnt-like-ingres.html
>
>