Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Ed Marshall
- Date:
- 2011-04-15 @ 21:49
(Apologies in advance for the long email. I really need to work on that.)
On Fri, Apr 15, 2011 at 10:00 AM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> The docs generation is going to change, so how are you doing it?
I'm not doing anything, that's the problem. ;-) I'm literally just
sucking the docs and examples directories into a mongrel2-docs
package, which isn't exactly ideal (in a perfect world, the RPM would
force the docs to be generated at build time, and put the HTML version
out in a web root that a default mongrel2 installation would have
access to view, much like httpd-docs currently works in Fedora).
If what you're doing with documentation is changing, I'll leave it
like this until you're happy with it.
> Oh yeah man pages would be good. I hate writing those. :-)
Okay, I'll probably spend a little time on building up some real man
pages from the existing documentation (and maybe spend a little time
seeing how they could be integrated, so there aren't two things to
edit when a command-line parameter changes).
>> - There's a couple of patches/changes that make life easier for
>> distribution packagers that I'd like to discuss here separately, to see
>> if they can make their way into Mongrel2 properly. (Some of them
>> wouldn't make any sense; they're just to satisfy Fedora requirements.)
>
> Send them on.
See Sabin's comment; I lifted a most of his Debian patches for the
RPM, with a few additions. :) (Thanks, Sabin!)
Basically, we're patching various makefiles to support a
"destdir"/alternative installation root, to keep our respective
packing toolchains happy.
We also change the default prefix of /usr/local to /usr; for most of
the Makefiles we didn't strictly need to do that, since you can
override it with an environment variable, but ssl/config.h sets PREFIX
and CONFIG_HTTP_LUA_PREFIX to /usr/local, which we correct. These are
pretty typical changes for RPMs (although typically they'd want to
re-generate something that says "autogenerated file" at the top of it
;-).
RPM complains about the format of the hashbang invocation on
examples/kegogi/tests/googletest.txt (I included it in the docs RPM),
so I patch it to use a fully-qualified pathname. Again, not a very big
deal, and a "problem of our own making".
The line-endings on docs/wiki/Donors.wiki, docs/lt/wiki/Donors.wiki,
and examples/bbs/client.py were mixed; I run a quick sed over those in
the spec, but I suspect you might want to clean those up in fossil. I
also sanitize file permissions across the examples directory.
I have to run iconv over examples/zcov/zcov/data/js/sorttable.js to
convert to UTF-8. This is strictly a Fedora requirement (please don't
shoot the messenger ;-). Another "rpmlint complained about it" item
was examples/chat/idiots (zero-length file); I wouldn't spend any time
worrying about either of these if I were you.
One last thing is that I push the mongrel2 binary into /usr/sbin
instead of /usr/bin; this is an FHS-compliance thing, mainly. (And I
should be putting procer in /usr/sbin as well; right now, I build that
as a "mongrel2-procer" package, but there's really no intrinsic tie to
mongrel2 other than the tarball it comes from, so I might package that
as simply "procer".)
I'll also need to add an init script (or whatever magic will be needed
for systemd in Fedora 15) and a set of sane defaults so that a user
can just "yum -y install mongrel2 && service start mongrel2" and have
a basic working webserver, preferably serving up the official
documentation. (I may borrow some of Dalton's init script for Gentoo
here. ;-)
----
One thing that I know will give the Fedora folks heartburn is how
third-party libraries have been integrated, and it's something I
haven't touched yet. Standing Fedora packaging policy is that bundled
libraries be packaged separately and applications dynamically linked
to them, wherever possible.
(The reasoning is that security errata can be pushed for a single
package, rather than rebuilding dependent software and auditing for
statically-linked users, and to keep the license boundaries clear. In
the first case, Boost is one of the biggest "offenders", even though
most of it ends up being inlined at build time anyway. :P In the
second case, it can clarify situations like halloc, which is
dual-licensed, for other users of the package.)
So, almost every subdirectory of src is affected.
The mongrel2 version of axTLS can't really live separately from
libtask, so I'd expect to get a pass on that one. However, it looks
like libtask wasn't modified much from rcox's original (it's hard to
tell, as there's significant whitespace difference between the task
directory and Russ' version on his website), so that might be a
potential item to separate.
It looks like halloc is basically untouched, so that one's probably
easy. kazlib looks the same.
bstrlib has a few additions, but not a lot of actual changes, which
could make it easy to separate out.
None of these are existing Fedora packages either, which adds to the
fun. :) Plus, I'm only looking at the 1.5 release; I haven't peeked in
fossil yet to see how far things have diverged there.
I honestly have no idea what a reasonable resolution to this would end
up looking like; I'd likely need to bring some of it up on the
fedora-packagers' mailing list (and I wouldn't necessarily expect
Mongrel2 releases to make this easier, as it's essentially a problem
of our own making).
But, I figured I'd mention it, in case anyone was interested in how
the sausage is made. ;-) The full documentation on getting a package
into Fedora is here:
https://fedoraproject.org/wiki/Packaging:Guidelines
https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
--
Ed Marshall <esm@logic.net>
Felix qui potuit rerum cognoscere causas.
http://esm.logic.net/
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Zed A. Shaw
- Date:
- 2011-04-15 @ 22:56
On Fri, Apr 15, 2011 at 04:49:36PM -0500, Ed Marshall wrote:
> https://fedoraproject.org/wiki/Packaging:Guidelines
> https://fedoraproject.org/wiki/Packaging:ReviewGuidelines
Also, where are you reading this requirement? I think you've misred it
if you mean this:
https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries
It's for *pre-built* binaries, not source code my project includes. So,
I couldn't include a special crypto tool that you needed for the build
as a binary, it has to build from source.
Can you show me the place where they require what you are referring to?
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Ed Marshall
- Date:
- 2011-04-16 @ 18:43
On Fri, Apr 15, 2011 at 5:56 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
>
>
https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries
>
Right, that's for the pre-built stuff; I was referring to the section on
bundled libraries (under "Duplication of system libraries" in the
guidelines):
https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries
I was very prepared for a "fuck that" response when I wrote it. ;-) Sorry, I
wasn't trying to raise your blood pressure; I just figured I'd explain one
of the challenges I might have getting this included if I decide to go down
that road (at a minimum, I'll keep building RPMs, even if I'm the only one
using them ;-).
Some of the libraries you include are what they'd call "copylibs", ie.
they're distributed by their upstream "project" with the intention of just
being included in another project as-is or intended to be adapted for use,
without formal releases or any of that jazz. ie. pastebins, "gists",
tarballs of a loose collection of .c/.h files, etc. Utility stuff that
nobody is really maintaining. But, if it actually has releases and a
maintainer, then they try to separate it out; the upstream project might be
good about fixing security issues, for example, but that doesn't mean that
downstream users that are bundling it are going to be as quick about it (or
will even be aware of updates).
You asked about Node...the answer is, they don't supply packages of it right
now. ;-) (Plus, they're at least fairly sane about duplication of
client-side-only javascript, not that it helps Node at all.) The process of
getting it approved has been a pretty long one, and is still going on (I
think they're on the second or third person trying to get it committed now).
A link, in case anyone wants to know what reviews look like for a
non-trivial package:
https://bugzilla.redhat.com/show_bug.cgi?id=634911
(And this doesn't include all the dependencies that needed to be packaged
first; v8, libeio, http-parser, and now node itself, then they'll start to
get into the npm packages, much like what happens today with python, ruby,
and perl packages.)
With some projects, handling this kind of thing is easy for the packager
(ie. "./configure --use-external-xyzlib"), with others it's a ton of work
(I've been building packages of Fritzing, which bundles a few libraries that
Fedora already packages). The whole thing isn't really meant to be a problem
for you, and I should have been a lot more clear about that; this is really
my problem, unless you decide you agree with them and think there's value in
dependencies modular within Mongrel2 itself.
(It's one of the strengths and weaknesses of the Fedora community: there are
rules, and by that, I mean a metric shit-ton of rules, which doesn't make
this stuff a whole lot of fun. But at the end of it, you wind up with a
fairly internally-consistent distribution to work with, as an
admin/end-user.)
--
Ed Marshall <esm@logic.net>
Felix qui potuit rerum cognoscere causas.
http://esm.logic.net/
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Zed A. Shaw
- Date:
- 2011-04-15 @ 22:53
On Fri, Apr 15, 2011 at 04:49:36PM -0500, Ed Marshall wrote:
Cool, I'll check out all this other stuff, but...
> One thing that I know will give the Fedora folks heartburn is how
> third-party libraries have been integrated, and it's something I
> haven't touched yet. Standing Fedora packaging policy is that bundled
> libraries be packaged separately and applications dynamically linked
> to them, wherever possible.
In two words: fuck them. Just 'cause I include some source code in my
library and you can also find another tar.gz with the same source
doesn't mean I have to make a library. If they bitch then I can trot
out a ton of projects that do this which I'm sure they just give a pass.
In fact, what do they do about Node? Those guys do this for the whole
setup.
> So, almost every subdirectory of src is affected.
...
> None of these are existing Fedora packages either, which adds to the
> fun. :) Plus, I'm only looking at the 1.5 release; I haven't peeked in
> fossil yet to see how far things have diverged there.
Yes, that's why that's a load of absolutely bullshit. If they are
planning on locking *my* webserver at some broke ass old version of a
library I use so taht *my* users bitch about it not working right then
no way. No other distro has this requirement, and my only thought is
they really do it for some anti-opensource business reason like RedHat
wants to relicense the software to commercial entities.
If this is their policy, then I'm sorry man but I'd say your work might
be for naught. Well, the packaging might be useful, but I wouldn't
bother submitting it. Their policy completely violates the way open
source works and I find it offensive that they want to carve up *my*
serve to suite their stupid needs.
Anyway, let me know if you keep building the package so I can decide to
fix the things you mention.
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Sabin Iacob
- Date:
- 2011-04-15 @ 18:03
On 04/15/2011 06:00 PM, Zed A. Shaw wrote:
>> - There's a couple of patches/changes that make life easier for
>> distribution packagers that I'd like to discuss here separately, to see
>> if they can make their way into Mongrel2 properly. (Some of them
>> wouldn't make any sense; they're just to satisfy Fedora requirements.)
> Send them on.
the destdir patch would be nice to have integrated, indeed; I avoided
bringing this up because, well, it's a packaging thing, but it seems
Ed's patch is identical with mine, so at least rpm and deb packaging
systems have similar needs here. I have another one that cleans up test
output (dpkg tools complain about binary files in the diff and die
otherwise), maybe it should go in as well
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Zed A. Shaw
- Date:
- 2011-04-15 @ 22:44
On Fri, Apr 15, 2011 at 09:03:05PM +0300, Sabin Iacob wrote:
> On 04/15/2011 06:00 PM, Zed A. Shaw wrote:
> the destdir patch would be nice to have integrated, indeed; I avoided
> bringing this up because, well, it's a packaging thing, but it seems
> Ed's patch is identical with mine, so at least rpm and deb packaging
> systems have similar needs here. I have another one that cleans up test
> output (dpkg tools complain about binary files in the diff and die
> otherwise), maybe it should go in as well
Send them, I'll apply them.
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Sabin Iacob
- Date:
- 2011-04-16 @ 14:29
On 04/16/2011 01:44 AM, Zed A. Shaw wrote:
> On Fri, Apr 15, 2011 at 09:03:05PM +0300, Sabin Iacob wrote:
>> On 04/15/2011 06:00 PM, Zed A. Shaw wrote:
>> the destdir patch would be nice to have integrated, indeed; I avoided
>> bringing this up because, well, it's a packaging thing, but it seems
>> Ed's patch is identical with mine, so at least rpm and deb packaging
>> systems have similar needs here. I have another one that cleans up test
>> output (dpkg tools complain about binary files in the diff and die
>> otherwise), maybe it should go in as well
> Send them, I'll apply them.
here ya go
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Zed A. Shaw
- Date:
- 2011-04-17 @ 03:37
On Sat, Apr 16, 2011 at 05:29:34PM +0300, Sabin Iacob wrote:
> >Send them, I'll apply them.
>
> here ya go
Alright, so question is: Should we just default to putting it in /usr
and then people can do /usr/local or should I put it back to /usr/local
and then you'll just have a small patch for your build?
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Sabin Iacob
- Date:
- 2011-04-17 @ 22:31
On 04/17/2011 06:37 AM, Zed A. Shaw wrote:
> On Sat, Apr 16, 2011 at 05:29:34PM +0300, Sabin Iacob wrote:
>>> Send them, I'll apply them.
>> here ya go
> Alright, so question is: Should we just default to putting it in /usr
> and then people can do /usr/local or should I put it back to /usr/local
> and then you'll just have a small patch for your build?
/usr/local by default (as it has been since the dawn of time), but easy
to change (in theory the current ?= should listen to PREFIX being
defined externally, but beyond obvious usage makefiles are sort of black
magic and I haven't had time to test); probably the biggest culprit, as
Ed said, is CONFIG_HTTP_LUA_PREFIX, I guess that could be added to
CFLAGS and the existing declaration wrapped in an #ifndef...#endif
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Alfred Tascon
- Date:
- 2011-04-17 @ 04:02
My vote goes to keep it at /usr/local
I currently use this fact for building deployment images which are right now
distro agnostic.
Alfred
On Sun, Apr 17, 2011 at 11:37 AM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Sat, Apr 16, 2011 at 05:29:34PM +0300, Sabin Iacob wrote:
> > >Send them, I'll apply them.
> >
> > here ya go
>
> Alright, so question is: Should we just default to putting it in /usr
> and then people can do /usr/local or should I put it back to /usr/local
> and then you'll just have a small patch for your build?
>
> --
> Zed A. Shaw
> http://zedshaw.com/
>
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Sebastian Otaegui
- Date:
- 2011-04-17 @ 18:01
Your default should be /usr/local the default for the maintainers build
should be the one changed.
On Sat, Apr 16, 2011 at 11:02 PM, Alfred Tascon <atascon@gmail.com> wrote:
> My vote goes to keep it at /usr/local
>
> I currently use this fact for building deployment images which are right
> now distro agnostic.
>
> Alfred
>
>
> On Sun, Apr 17, 2011 at 11:37 AM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
>
>> On Sat, Apr 16, 2011 at 05:29:34PM +0300, Sabin Iacob wrote:
>> > >Send them, I'll apply them.
>> >
>> > here ya go
>>
>> Alright, so question is: Should we just default to putting it in /usr
>> and then people can do /usr/local or should I put it back to /usr/local
>> and then you'll just have a small patch for your build?
>>
>> --
>> Zed A. Shaw
>> http://zedshaw.com/
>>
>
>
--
Those who do not understand Unix are condemned to reinvent it, poorly.
Any sufficiently recent Microsoft OS contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of Unix.
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- joshua simmons
- Date:
- 2011-04-17 @ 03:38
/usr/local/ should be the default for sure.
On Sun, Apr 17, 2011 at 1:37 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote:
> On Sat, Apr 16, 2011 at 05:29:34PM +0300, Sabin Iacob wrote:
> > >Send them, I'll apply them.
> >
> > here ya go
>
> Alright, so question is: Should we just default to putting it in /usr
> and then people can do /usr/local or should I put it back to /usr/local
> and then you'll just have a small patch for your build?
>
> --
> Zed A. Shaw
> http://zedshaw.com/
>
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Dalton Barreto
- Date:
- 2011-04-15 @ 18:24
2011/4/15 Sabin Iacob <iacobs@m0n5t3r.info>:
> On 04/15/2011 06:00 PM, Zed A. Shaw wrote:
>>> - There's a couple of patches/changes that make life easier for
>>> distribution packagers that I'd like to discuss here separately, to see
>>> if they can make their way into Mongrel2 properly. (Some of them
>>> wouldn't make any sense; they're just to satisfy Fedora requirements.)
>> Send them on.
>
> the destdir patch would be nice to have integrated, indeed; I avoided
> bringing this up because, well, it's a packaging thing, but it seems
> Ed's patch is identical with mine,
This is also related to my patch. I wrote Gentoo ebuilds for mongrel2.
Gentoo's package system
always passes a variable named ${prefix} to the make install command,
so the difference to my patch is that
I changed from:
PREFIX=/usr/local
to
prefix=${prefix:-/usr/local}
the ebuilds for mongrel2 are here:
https://github.com/daltonmatos/gentoo-overlay/tree/master/www-servers/mongrel2
Thanks.
--
Dalton Barreto
http://daltonmatos.wordpress.com
http://wsgid.com
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Zed A. Shaw
- Date:
- 2011-04-15 @ 22:46
On Fri, Apr 15, 2011 at 03:24:41PM -0300, Dalton Barreto wrote:
> This is also related to my patch. I wrote Gentoo ebuilds for mongrel2.
> Gentoo's package system
> always passes a variable named ${prefix} to the make install command,
> so the difference to my patch is that
Wait, no other distro does this, why is Gentoo different? It's been
PREFIX all caps since the dawn of time AFAIK.
--
Zed A. Shaw
http://zedshaw.com/
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Dalton Barreto
- Date:
- 2011-04-15 @ 23:26
2011/4/15 Zed A. Shaw <zedshaw@zedshaw.com>:
> On Fri, Apr 15, 2011 at 03:24:41PM -0300, Dalton Barreto wrote:
>> This is also related to my patch. I wrote Gentoo ebuilds for mongrel2.
>> Gentoo's package system
>> always passes a variable named ${prefix} to the make install command,
>> so the difference to my patch is that
>
> Wait, no other distro does this, why is Gentoo different? It's been
> PREFIX all caps since the dawn of time AFAIK.
>
I have no idea. I'm used to write PREFIX too. But anyway, ok not to
apply my patch. No problem if the patch remains only for my gentoo
ebuild.
In fact, it seems that the command line used by gentoo to build the
packages are case-mixed:
${MAKE:-make} prefix="${D}usr" \
datadir="${D}usr/share" \
infodir="${D}usr/share/info" \
localstatedir="${D}var/lib" \
mandir="${D}usr/share/man" \
sysconfdir="${D}etc" \
${LOCAL_EXTRA_EINSTALL} \
${MAKEOPTS} ${EXTRA_EMAKE} -j1 \
"$@" install || die "einstall failed"
go figure...
--
Dalton Barreto
http://daltonmatos.wordpress.com
http://wsgid.com
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Lionel Orry
- Date:
- 2011-04-16 @ 06:01
On Sat, Apr 16, 2011 at 1:26 AM, Dalton Barreto <daltonmatos@gmail.com> wrote:
> 2011/4/15 Zed A. Shaw <zedshaw@zedshaw.com>:
>> On Fri, Apr 15, 2011 at 03:24:41PM -0300, Dalton Barreto wrote:
>>> This is also related to my patch. I wrote Gentoo ebuilds for mongrel2.
>>> Gentoo's package system
>>> always passes a variable named ${prefix} to the make install command,
>>> so the difference to my patch is that
>>
>> Wait, no other distro does this, why is Gentoo different? It's been
>> PREFIX all caps since the dawn of time AFAIK.
>>
>
> I have no idea. I'm used to write PREFIX too. But anyway, ok not to
> apply my patch. No problem if the patch remains only for my gentoo
> ebuild.
>
> In fact, it seems that the command line used by gentoo to build the
> packages are case-mixed:
>
> ${MAKE:-make} prefix="${D}usr" \
> datadir="${D}usr/share" \
> infodir="${D}usr/share/info" \
> localstatedir="${D}var/lib" \
> mandir="${D}usr/share/man" \
> sysconfdir="${D}etc" \
> ${LOCAL_EXTRA_EINSTALL} \
> ${MAKEOPTS} ${EXTRA_EMAKE} -j1 \
> "$@" install || die "einstall failed"
>
>
> go figure...
That may have to do with the "einstall" command. AFAIR, it's
recommended to use "emake install" instead, and maybe the latter uses
PREFIX instead... I'm not expert but it's worth having a look at the
gentoo devmanual. Or use "emake install prefix=${PREFIX}" maybe, but I
don't think it's necessary. As Zed says it's a standard to use PREFIX
and I suppose we don't customize ebuilds for standard makefiles and
default options just go fine.
Lionel
>
> --
> Dalton Barreto
> http://daltonmatos.wordpress.com
> http://wsgid.com
>
Re: [mongrel2] Mongrel2 RPMs for Fedora
- From:
- Lionel Orry
- Date:
- 2011-04-16 @ 06:15
On Sat, Apr 16, 2011 at 8:01 AM, Lionel Orry <lionel.orry@gmail.com> wrote:
> On Sat, Apr 16, 2011 at 1:26 AM, Dalton Barreto <daltonmatos@gmail.com> wrote:
>> 2011/4/15 Zed A. Shaw <zedshaw@zedshaw.com>:
>>> On Fri, Apr 15, 2011 at 03:24:41PM -0300, Dalton Barreto wrote:
>>>> This is also related to my patch. I wrote Gentoo ebuilds for mongrel2.
>>>> Gentoo's package system
>>>> always passes a variable named ${prefix} to the make install command,
>>>> so the difference to my patch is that
>>>
>>> Wait, no other distro does this, why is Gentoo different? It's been
>>> PREFIX all caps since the dawn of time AFAIK.
>>>
>>
>> I have no idea. I'm used to write PREFIX too. But anyway, ok not to
>> apply my patch. No problem if the patch remains only for my gentoo
>> ebuild.
>>
>> In fact, it seems that the command line used by gentoo to build the
>> packages are case-mixed:
>>
>> ${MAKE:-make} prefix="${D}usr" \
>> datadir="${D}usr/share" \
>> infodir="${D}usr/share/info" \
>> localstatedir="${D}var/lib" \
>> mandir="${D}usr/share/man" \
>> sysconfdir="${D}etc" \
>> ${LOCAL_EXTRA_EINSTALL} \
>> ${MAKEOPTS} ${EXTRA_EMAKE} -j1 \
>> "$@" install || die "einstall failed"
>>
>>
>> go figure...
>
> That may have to do with the "einstall" command. AFAIR, it's
> recommended to use "emake install" instead, and maybe the latter uses
> PREFIX instead... I'm not expert but it's worth having a look at the
> gentoo devmanual. Or use "emake install prefix=${PREFIX}" maybe, but I
> don't think it's necessary. As Zed says it's a standard to use PREFIX
> and I suppose we don't customize ebuilds for standard makefiles and
> default options just go fine.
>
> Lionel
Sorry for the spam. I went deeper into the 'man 5 ebuild' page and it
seems to me that it has something to do with the fact that the prefix
is usually expected in the configure step, which is absent for
mongrel2. So I believe the line should be exactly
emake install DESTDIR=${D} PREFIX="${EPREFIX}"/usr
(this line should be quite portable over gentoo variants, notably
Gentoo Prefix which I personally use.)
Lionel
>
>>
>> --
>> Dalton Barreto
>> http://daltonmatos.wordpress.com
>> http://wsgid.com
>>
>