[gentoo-dev] How to fix pathnames in .ebuilds

[gentoo-dev] How to fix pathnames in .ebuilds

[Martin Lesser]

I try to create an ebuild for ghfaxviewer and have some problems
with an absolute path (/usr/share/pixmaps) in the Makefile which result
in 'access violation' errors.

econf() replaces --datadir with /usr/share. When einstall() is called
--datadir is changed to ${D}/usr/share but the depending PIXMAPS_DIR is
not changed to ${D}/usr/share/pixmaps cause it was written to the
Makefiles in the configure step before.

What's the recommended and simplest way to fix such issues? The ebuild
HOWTO did not help me and also the hints in the forums could not help
me.

Martin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] How to fix pathnames in .ebuilds

[Alastair Tse]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

On Thu, 2003-07-10 at 13:16, Martin Lesser wrote:
> econf() replaces --datadir with /usr/share. When einstall() is called
> --datadir is changed to ${D}/usr/share but the depending PIXMAPS_DIR is
> not changed to ${D}/usr/share/pixmaps cause it was written to the
> Makefiles in the configure step before.

Do the Makefiles use the variable DESTDIR ? If they do, then use:

make DESTDIR=${D} install || die "install failed"

Otherwise, it could be that a particular variable needs to be set in
addition to einstall (if you choose to use it). You'll have to delve
into the file, find the variable that is set to /usr/share/pixmaps and
override it using something like:

einstall pixmapdir=${D}/usr/share/pixmaps

> What's the recommended and simplest way to fix such issues? The ebuild
> HOWTO did not help me and also the hints in the forums could not help
> me.

The best way of learning is to look at how other ebuilds do it. Maybe
someone can write an ebuild FAQ to document all the tricks that are in
use :)

Cheers,
-- 
Alastair 'liquidx' Tse
 >> Gentoo Developer
 >> http://www.liquidx.net/ | http://dev.gentoo.org/~liquidx/
 >> GPG Key : http://dev.gentoo.org/~liquidx/liquidx_gentoo_org.asc
 >> FingerPrint : 579A 9B0E 43E8 0E40 EE93  BB1C 38CE 1C7B 3907 14F6

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] How to fix pathnames in .ebuilds

[Martin Lesser]

Grant Goodyear <g2boojum@gentoo.org> writes:

> On Thu, 2003-07-10 at 08:16, Martin Lesser wrote:
> > I try to create an ebuild for ghfaxviewer and have some problems
> > with an absolute path (/usr/share/pixmaps) in the Makefile which result
> > in 'access violation' errors.
> *Sigh*  In such cases you need to patch (or sed -ie) the makefile so
> that it installs to ${D}/usr/share/pixmaps.  Please make a note of this
> change when you submit the ebuild to bugs.gentoo.org so that we can
> contact the program developers and ask them to fix that glitch.

The hint given by Alastair did it mostly. Two additional variables in
src_install() did the rest.

Before reporting this ebuild to bugs.gentoo.org I would like to know how
long the "normal" period is between reporting a new ebuild and finding
this ebuild in the portage tree (or getting any other response)- another
ebuild was added on 05/31/03
(http://bugs.gentoo.org/show_bug.cgi?id=22000) but since then not much
happened...

IMO creating or reporting ebuilds which perhaps are only helpful here
doesn't make much sense.

Martin

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] How to fix pathnames in .ebuilds

[Patrick Kursawe]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

On Thu, Jul 10, 2003 at 06:31:32PM +0200, Martin Lesser wrote:
> Before reporting this ebuild to bugs.gentoo.org I would like to know how
> long the "normal" period is between reporting a new ebuild and finding
> this ebuild in the portage tree (or getting any other response)- another
> ebuild was added on 05/31/03
> (http://bugs.gentoo.org/show_bug.cgi?id=22000) but since then not much
> happened...

I'm afraid there is nothing like a "normal" period. It depends on quite
a few factors... for example, if a developer is interested in the program,
if he thinks he will be able to maintain it, how clean the ebuild looks,
air pressure, moon phase...	

> IMO creating or reporting ebuilds which perhaps are only helpful here
> doesn't make much sense.

Perhaps someone else who needs it will find it when searching
bugs.gentoo.org for it. Try to see it as a "user contributed ebuilds"
database aswell.

Bye, Patrick

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] How to fix pathnames in .ebuilds

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1523 bytes --]

On Friday 11 July 2003 07:40, Patrick Kursawe wrote:
> On Thu, Jul 10, 2003 at 06:31:32PM +0200, Martin Lesser wrote:
> > Before reporting this ebuild to bugs.gentoo.org I would like to know how
> > long the "normal" period is between reporting a new ebuild and finding
> > this ebuild in the portage tree (or getting any other response)- another
> > ebuild was added on 05/31/03
> > (http://bugs.gentoo.org/show_bug.cgi?id=22000) but since then not much
> > happened...
>
> I'm afraid there is nothing like a "normal" period. It depends on quite
> a few factors... for example, if a developer is interested in the program,
> if he thinks he will be able to maintain it, how clean the ebuild looks,
> air pressure, moon phase...
>
> > IMO creating or reporting ebuilds which perhaps are only helpful here
> > doesn't make much sense.
>
> Perhaps someone else who needs it will find it when searching
> bugs.gentoo.org for it. Try to see it as a "user contributed ebuilds"
> database aswell.

Also, ebuilds that go to big projects as kde and gnome will probably take more 
time. There are very many kde and gnome programs with various functions. The 
herds project aims to divide those to more projects, so that a kde sound 
editor will go to the sound project, not to kde. That should help things as 
the members of the kde and gnome projects do not use every kind of program 
themselves.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.cs.kun.nl/~pauldv

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] How to fix pathnames in .ebuilds

[Stanislav Brabec]

Alastair Tse wrote:
> On Thu, 2003-07-10 at 13:16, Martin Lesser wrote:

> make DESTDIR=${D} install || die "install failed"
> 
Yes, it is the correct and recommended solution! See "info automake" for
more.

But einstall still uses ancient way:

                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 \
                    "$@" install

This way works for many packages and in past it was the only way, but it
is basically incorrect - those values has influence to compiler and
linker, not only for destination paths! This is the reason why automake
developers has added DESTDIR, which is designed to have no influence to
compiler.

Please change the default in portage and rename current einstall to
old_einstall.

Well, there are some bad projects, which installs OK with this old way,
but not with DESTDIR, but it's better to use autoreconf or write a fix.

Why?

Changing prefix-based dirs is very dangerous way to install automake
based projects and can lead to access violation or even to mis-compiled
projects!

1) Many paths (e. g. PIXMAPS_DIR) are evaluated in configure time and
this install hack does not change it.

2) Purpose of all these variables is definition of default paths for
compiler and linker. If package recompiles/links something during
install process, it changes default path compiled into binary/library.


OT:
Similar problem exists also for libraries:

Do not use LDFLAGS and CPPFLAGS for references to build root - use
LIBRARY_PATH and CPATH (C_INCLUDE_PATH, CPLUS_INCLUDE_PATH,
OBJC_INCLUDE_PATH). Otherwise you will get library with incorrect
hardwired paths either to binary/library or to la file.
It is security hole, if la file points to /var/tmp.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx


--
gentoo-dev@gentoo.org mailing list