FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 02-23-2010, 04:33 AM
Iain Arnell
 
Default Inclusion of Ingres RDBMS in Fedora

On Tue, Feb 23, 2010 at 4:09 AM, Jay Hankinson
<jeremy.hankinson@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

> 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.

> 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.

> * * * 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.

> * * * Executable stack code

Maybe it doesn't need this [1].

> 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.

> 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!

[1] http://community.ingres.com/forum/dba-forum/11683-fedora-12-64bit-selinux-doesnt-like-ingres.html

--
Iain.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-23-2010, 05:40 AM
Ville Skyttä
 
Default Inclusion of Ingres RDBMS in Fedora

On Tuesday 23 February 2010, Iain Arnell wrote:
> On Tue, Feb 23, 2010 at 4:09 AM, Jay Hankinson
> > * 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.

There is also a bug report against rpmlint about $ORIGIN rpaths:
https://bugzilla.redhat.com/show_bug.cgi?id=436486

I'm not qualified to say whether this is something that should be fixed in
rpmlint (and if, exactly how), or is it right in complaining about it.
/usr/lib/rpm/check-rpaths-worker does have some documentation; it appears to
accept $ORIGIN after other rpaths. The packaging guidelines do not mention
anything special about $ORIGIN rpaths. Could someone who knows about this
more comment?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-23-2010, 03:34 PM
Jay Hankinson
 
Default Inclusion of Ingres RDBMS in Fedora

On 2/22/10 9:33 PM, Iain Arnell wrote:
> On Tue, Feb 23, 2010 at 4:09 AM, Jay Hankinson
> <jeremy.hankinson@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
>
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 01:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org