* [gentoo-dev] ebuild question
@ 2001-08-05 15:50 Craig Joly
2001-08-05 17:07 ` Daniel Robbins
0 siblings, 1 reply; 56+ messages in thread
From: Craig Joly @ 2001-08-05 15:50 UTC (permalink / raw
To: Gentoo Developers
Has it ever been suggested to add an src_configure() section to the
ebuild file? It would be useful to be able to type
"ebuild foo.ebuild configure" and then look at the generated
makefiles.
Craig
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2001-08-05 15:50 Craig Joly
@ 2001-08-05 17:07 ` Daniel Robbins
0 siblings, 0 replies; 56+ messages in thread
From: Daniel Robbins @ 2001-08-05 17:07 UTC (permalink / raw
To: gentoo-dev
On Sun, Aug 05, 2001 at 04:01:11PM -0600, Craig Joly wrote:
> Has it ever been suggested to add an src_configure() section to the ebuild
> file? It would be useful to be able to type "ebuild foo.ebuild configure"
> and then look at the generated makefiles.
Yes, this has been suggested many times. Right now, it's all done in
src_compile() as you know. Moving it to its own function would require fixing
all our existing Makefiles, I think. Well, I can probably retrofit that
feature; when I have time, I'll see what I can do.
--
Daniel Robbins <drobbins@gentoo.org>
Chief Architect/President http://www.gentoo.org
Gentoo Technologies, Inc.
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] ebuild question
@ 2002-02-07 3:44 Edward Muller
2002-02-07 4:43 ` Tod M Neidt
0 siblings, 1 reply; 56+ messages in thread
From: Edward Muller @ 2002-02-07 3:44 UTC (permalink / raw
To: gentoo-dev
I need to build new oaf, ORBIT & bonobo ebuilds for the current builds.
I was looking at the current ORBit-0.5.13 ebuild and found the
followings types of lines:
...
docinto idl
...
What is docinto. I can't seem to find the script in /usr/lib/portage/bin
and a look at the developer docs on the website didn't mention docinto.
Is it an old script? Is it undocumented (and if, so why and where is it
kept?) Or did I miss something?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2002-02-07 3:44 Edward Muller
@ 2002-02-07 4:43 ` Tod M Neidt
0 siblings, 0 replies; 56+ messages in thread
From: Tod M Neidt @ 2002-02-07 4:43 UTC (permalink / raw
To: gentoo-dev
On Wed, 2002-02-06 at 21:44, Edward Muller wrote:
> I need to build new oaf, ORBIT & bonobo ebuilds for the current builds.
> I was looking at the current ORBit-0.5.13 ebuild and found the
> followings types of lines:
>
> ...
> docinto idl
> ...
>
> What is docinto. I can't seem to find the script in /usr/lib/portage/bin
> and a look at the developer docs on the website didn't mention docinto.
> Is it an old script? Is it undocumented (and if, so why and where is it
> kept?) Or did I miss something?
>
Hi!
docinto is an internal function of /usr/sbin/ebuild.sh
If you run across a something lke that in an ebuild that isn't in
/usr/lib/portage/bin in can often be found in /usr/sbin/ebuild.sh
Hope that helps,
tod
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2002-04-17 5:21 Richard Jackson
@ 2002-04-17 5:02 ` Jared H. Hudson
2002-04-17 6:05 ` Richard Jackson
0 siblings, 1 reply; 56+ messages in thread
From: Jared H. Hudson @ 2002-04-17 5:02 UTC (permalink / raw
To: gentoo-dev
> Should I compile all 4 of them? Yes doing this would take some bash magic but
> not too much. If I should do all four of them what naming convention should I
> use for the differant executables? Some thing like nethackQt nethackGnome?
I would say yes, do this. If you need an example, look at:
app-editors/vim for example, it builds a GUI version and a non-GUI version.
It's really not that hard. The way I would lay it out is:
# handle use options common to all types
use foo && myconf="$myconf --enable-foo"
use foo2 && myconf="$myconf --enable-foo2"
# handle first possible build type
if [ "`use gnome`" ];
then
./configure --prefix=/usr --host=$CHOST \
--mandir=/usr/share/man --enable-gtk --enable-gnome $myconf \
|| die "gnome & gtk configure failed"
emake || die "gnome & gtk make failed"
mv src/foo src/gfoo
fi
# handle second possible build type
if [ "`use kde`" ];
then
./configure --prefix=/usr --host=$CHOST \
--mandir=/usr/share/man --enable-qt --enable-kde $myconf \
|| die "kde & qt configure failed"
emake || die "kde & qt make failed"
mv src/foo src/kfoo
fi
# handle normal build type
./configure --prefix=/usr --host=$CHOST \
--mandir=/usr/share/man $myconf \
|| die "normal configure failed"
emake || die "normal make failed"
My example may not be perfect, but you get the idea (I hope)
-Jared H.
>
> Should I just pick one of them and compile that one? What if I pick the one
> the user doesn't want?
>
> Should I force some user interaction with the build process? Other words ask
> them which one they want? I don't really like this option myself.
>
> And now even more questions.
> On instalation of the above should I create menu items in KDE and GNOME if the
> user has them? And a side question to that is it seems that KDE does not
> automaticly include the GNOME apps but GNOME does automaticly include he KDE
> apps so if I'm doing a KDE build should I add it to the GNOME menu if they
> have it. And the reverse if I'm doing a GNOME build should I add that to the
> KDE menus?
>
> Any thoughts on the above would be helpfull.
> Thanks
> Richard Jackson
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2002-04-17 6:05 ` Richard Jackson
@ 2002-04-17 5:21 ` Jared H. Hudson
0 siblings, 0 replies; 56+ messages in thread
From: Jared H. Hudson @ 2002-04-17 5:21 UTC (permalink / raw
To: gentoo-dev
I would not use the vim ebuild as a good example of a ebuild to learn
from. It's harder to understand than most and does a lot of things most
ebuilds don't need to do. But I would use it as an example of how to
build to things at the same time, like your case requires.
-Jared H.
Richard Jackson wrote:
> On Wednesday 17 April 2002 12:02 am, Jared H. Hudson wrote:
>
>>>Should I compile all 4 of them? Yes doing this would take some bash magic
>>>but not too much. If I should do all four of them what naming convention
>>>should I use for the differant executables? Some thing like nethackQt
>>>nethackGnome?
>>
>>I would say yes, do this. If you need an example, look at:
>>app-editors/vim for example, it builds a GUI version and a non-GUI version.
>>
>>It's really not that hard. The way I would lay it out is:
>>
>># handle use options common to all types
>>use foo && myconf="$myconf --enable-foo"
>>use foo2 && myconf="$myconf --enable-foo2"
>>
>># handle first possible build type
>>if [ "`use gnome`" ];
>>then
>> ./configure --prefix=/usr --host=$CHOST \
>> --mandir=/usr/share/man --enable-gtk --enable-gnome $myconf \
>>
>> || die "gnome & gtk configure failed"
>>
>> emake || die "gnome & gtk make failed"
>>
>> mv src/foo src/gfoo
>>fi
>>
>># handle second possible build type
>>if [ "`use kde`" ];
>>then
>> ./configure --prefix=/usr --host=$CHOST \
>> --mandir=/usr/share/man --enable-qt --enable-kde $myconf \
>>
>> || die "kde & qt configure failed"
>>
>> emake || die "kde & qt make failed"
>>
>> mv src/foo src/kfoo
>>fi
>>
>># handle normal build type
>>./configure --prefix=/usr --host=$CHOST \
>>--mandir=/usr/share/man $myconf \
>>
>>|| die "normal configure failed"
>>
>>emake || die "normal make failed"
>>
>>
>>My example may not be perfect, but you get the idea (I hope)
>>
>
> Kinda of what I was looking at doing. The differance is that basicly I have to
> have a clean source directory for each step because you have to modify the
> make files as nethack does not use automake so I have a patch for each option
> that has to be applied to the clean sources. And of couse each of them will
> install on top of the other when you get to the install process so I was
> looking at handling that myself so things would be done right as far as each
> version goes that is. It is kinda of a pain but doable. I will take a look at
> the vim ebuild though as I'm still not real strait on some of the vars used
> in the ebuild files. I gues I need to reread the howto again.
>
> Richard jackson
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] ebuild question
@ 2002-04-17 5:21 Richard Jackson
2002-04-17 5:02 ` Jared H. Hudson
0 siblings, 1 reply; 56+ messages in thread
From: Richard Jackson @ 2002-04-17 5:21 UTC (permalink / raw
To: gentoo-dev
I have a ebuild script question. I'm working on adding Qt 3 to nethack. I
think I saw a post at one point that someone else was doing this as well.
Either way I'm going to do this as an educational experance. When I have it
clean I will track down the other person working on it and see if they want
what I have done. If not I will just calk it up to experance. I picked this
one becase it has some uniqe issues and I thought if I could get this one
right then the experance will help latter on.
Now to the question.
Nethack is uniqe in that it can be compiled many differant ways
1) Console - This is currently the only option
2) Qt 3 or 2 - I have this one pretty much done using Qt 3.
3) X11
4) KDE
5) Gnome
The problem with this is that what it looks to be doing is compiling in
support for Console and one widget set into one executable. And I can't seem
to beable to get all 5 options to work at one time witch I kinda figured it
wouldn't. So lets say the user has this in his/her USE statment:
USE="qt x11 kde gnome"
How would I go about handling the compile?
Should I compile all 4 of them? Yes doing this would take some bash magic but
not too much. If I should do all four of them what naming convention should I
use for the differant executables? Some thing like nethackQt nethackGnome?
Should I just pick one of them and compile that one? What if I pick the one
the user doesn't want?
Should I force some user interaction with the build process? Other words ask
them which one they want? I don't really like this option myself.
And now even more questions.
On instalation of the above should I create menu items in KDE and GNOME if the
user has them? And a side question to that is it seems that KDE does not
automaticly include the GNOME apps but GNOME does automaticly include he KDE
apps so if I'm doing a KDE build should I add it to the GNOME menu if they
have it. And the reverse if I'm doing a GNOME build should I add that to the
KDE menus?
Any thoughts on the above would be helpfull.
Thanks
Richard Jackson
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2002-04-17 5:02 ` Jared H. Hudson
@ 2002-04-17 6:05 ` Richard Jackson
2002-04-17 5:21 ` Jared H. Hudson
0 siblings, 1 reply; 56+ messages in thread
From: Richard Jackson @ 2002-04-17 6:05 UTC (permalink / raw
To: gentoo-dev
On Wednesday 17 April 2002 12:02 am, Jared H. Hudson wrote:
> > Should I compile all 4 of them? Yes doing this would take some bash magic
> > but not too much. If I should do all four of them what naming convention
> > should I use for the differant executables? Some thing like nethackQt
> > nethackGnome?
>
> I would say yes, do this. If you need an example, look at:
> app-editors/vim for example, it builds a GUI version and a non-GUI version.
>
> It's really not that hard. The way I would lay it out is:
>
> # handle use options common to all types
> use foo && myconf="$myconf --enable-foo"
> use foo2 && myconf="$myconf --enable-foo2"
>
> # handle first possible build type
> if [ "`use gnome`" ];
> then
> ./configure --prefix=/usr --host=$CHOST \
> --mandir=/usr/share/man --enable-gtk --enable-gnome $myconf \
>
> || die "gnome & gtk configure failed"
>
> emake || die "gnome & gtk make failed"
>
> mv src/foo src/gfoo
> fi
>
> # handle second possible build type
> if [ "`use kde`" ];
> then
> ./configure --prefix=/usr --host=$CHOST \
> --mandir=/usr/share/man --enable-qt --enable-kde $myconf \
>
> || die "kde & qt configure failed"
>
> emake || die "kde & qt make failed"
>
> mv src/foo src/kfoo
> fi
>
> # handle normal build type
> ./configure --prefix=/usr --host=$CHOST \
> --mandir=/usr/share/man $myconf \
>
> || die "normal configure failed"
>
> emake || die "normal make failed"
>
>
> My example may not be perfect, but you get the idea (I hope)
>
Kinda of what I was looking at doing. The differance is that basicly I have to
have a clean source directory for each step because you have to modify the
make files as nethack does not use automake so I have a patch for each option
that has to be applied to the clean sources. And of couse each of them will
install on top of the other when you get to the install process so I was
looking at handling that myself so things would be done right as far as each
version goes that is. It is kinda of a pain but doable. I will take a look at
the vim ebuild though as I'm still not real strait on some of the vars used
in the ebuild files. I gues I need to reread the howto again.
Richard jackson
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] ebuild question
@ 2002-04-18 6:13 Avi Schwartz
2002-04-18 6:59 ` George Shapovalov
2002-04-18 7:15 ` Tod M Neidt
0 siblings, 2 replies; 56+ messages in thread
From: Avi Schwartz @ 2002-04-18 6:13 UTC (permalink / raw
To: Gentoo Dev
I am trying to create an ebuild for wingide. I have couple of problems
I trying to solve here:
1. The name of the archive is wingide-1.1.3-1.tar.gz. I tried to call
the ebuild file wingide-1.1.3-1.ebuild but ebuild doesn't like it since
it thinks there are two version numbers. So I changed the name to
wingide-1.1.3-r1.ebuild and I am sticking the -1 in the code:
SRC_URI="ftp://ftp.wingide.com/pub/wingide/${PV}/${P}-1.tar.gzftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/macro-bugfix-all-${PV}-1.tar ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/print-bugfix-all-${PV}-1.tar ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/reuse-app-instance-all-${PV}-1.tar"
Is this an acceptable practice? The problem with this is that if they
come out with a -2 version, it will not be enough to rename the ebuild
file (although the bug fix files are breaking this anyway).
BTW, PV and ${D} are not documented in the developers HOWTO. What else
is missing?
2. Wingide comes with its own installation program which can be
controlled through the command line. When its archive is expanded, it
creates a wingide-1.1.3-1 directory in which there is the installation
program and the program files. Ho do I point to the installation
program? I tried the following ${WORKDIR}/${P}-1/wing-install.py, is
this correct?
3. The parameters it expects are the installation directory and binary
directory:
${WORKDIR}/${P}-1/wing-install.py \
--winghome ${D}/usr/lib/wingide \
--bin-dir ${D}/usr/bin
again, does this make sense?
4. Another problem I am having is that I see the following messages when
doing the install:
>>> Install wingide-1.1.3-r1 into
/var/tmp/portage/wingide-1.1.3-r1/image/ category avi
but when I look at the image directory I see that it didn't install a
thing.
5. The last 3 files are archives that have to be extracted over the root
installation directory which will be ${D}/usr/lib/wingide. Again, how
does one achieve this?
6. The compile stage extracts all 4 files while I realy want only the
main file to be extracted since the other 3 need to be extracted over
the installed file. Is there a way to control this? I tried to put my
own code in src_compile(), but ebuild goes ahead and extracts the
archives before executing my code.
7. When the wingide archive is extracted, besides the installation
program there is another tar file extracted which containsall the files.
Another possibility for the installation of the main wingide archive is
to just extract this archive into ${D}/usr/lib. The question is, do I
have to create ${D}/usr/lib if it doesn't exist yet or will ebuild do it
for me?
Thanks,
Avi
--
Avi Schwartz
avi@CFFtechnologies.com
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2002-04-18 6:13 Avi Schwartz
@ 2002-04-18 6:59 ` George Shapovalov
2002-04-18 7:15 ` Tod M Neidt
1 sibling, 0 replies; 56+ messages in thread
From: George Shapovalov @ 2002-04-18 6:59 UTC (permalink / raw
To: gentoo-dev
Hi
It is hard to answer many of these questions without seeing the package and
ebuild. However I'll try.
On Wednesday 17 April 2002 23:13, Avi Schwartz wrote:
> I am trying to create an ebuild for wingide. I have couple of problems
> I trying to solve here:
>
> 1. The name of the archive is wingide-1.1.3-1.tar.gz. I tried to call
> the ebuild file wingide-1.1.3-1.ebuild but ebuild doesn't like it since
> it thinks there are two version numbers. So I changed the name to
> wingide-1.1.3-r1.ebuild and I am sticking the -1 in the code:
[skipped]
> Is this an acceptable practice? The problem with this is that if they
> come out with a -2 version, it will not be enough to rename the ebuild
> file (although the bug fix files are breaking this anyway).
At least this is what you can find in some ebuilds. And it seems to be the
easiest way to go around here. You also would probably want to set your
${S}=${WORKDIR}/${P}-1.
>
> BTW, PV and ${D} are not documented in the developers HOWTO. What else
> is missing?
I hope I finally will get some time to update this part of instructions. I was
going to prepare the list of all vars portage generates when it parses ebuild
and link to it from the existing ebuild composition howto. I would appreciate
suggestion on what else should be covered.
>
> 2. Wingide comes with its own installation program which can be
> controlled through the command line. When its archive is expanded, it
> creates a wingide-1.1.3-1 directory in which there is the installation
> program and the program files. Ho do I point to the installation
> program? I tried the following ${WORKDIR}/${P}-1/wing-install.py, is
> this correct?
Does it work? In order to check this you can issue ebuild
wingide-1.1.3-1.ebuild unpack and then go to
/var/tmp/portage/wingide-1.1.3-1/work and see what goes where.
>
> 3. The parameters it expects are the installation directory and binary
> directory:
>
> ${WORKDIR}/${P}-1/wing-install.py \
> --winghome ${D}/usr/lib/wingide \
> --bin-dir ${D}/usr/bin
>
> again, does this make sense?
Is this analog of configure script or of make install?
You do not want anything that gets compiled or somehow setup to get an idea
that it lives under ${D}. However you do want it to be installed under ${D}.
> 5. The last 3 files are archives that have to be extracted over the root
> installation directory which will be ${D}/usr/lib/wingide. Again, how
> does one achieve this?
what about this?
cd ${D}/usr/lib/wingide
tar xzpf file
> 6. The compile stage extracts all 4 files while I really want only the
> main file to be extracted since the other 3 need to be extracted over
> the installed file. Is there a way to control this? I tried to put my
> own code in src_compile(), but ebuild goes ahead and extracts the
> archives before executing my code.
Are you talking about unpack or compile stage? When the files are extracted?
You might need to provide src_unpack function to do custom stuff.
> 7. When the wingide archive is extracted, besides the installation
> program there is another tar file extracted which containsall the files.
> Another possibility for the installation of the main wingide archive is
> to just extract this archive into ${D}/usr/lib. The question is, do I
> have to create ${D}/usr/lib if it doesn't exist yet or will ebuild do it
> for me?
I think you do. I am not totally clear on what are you trying to achieve here
though. Besides this is you who tells ebuild what to do and if the dir was
not created by the package installation scripts ebuild will not know to
create it on itself.
BTW, is this a prebuilt package or can it be compiled (the last one is always
preferable). Is this a WingIDE by any chance? Is this a (time-limited) demo
version? I think the users are required to register on the site when
downloading the product (in order to get the license). You will most likely
have to do something about it (I am not really sure on the status of this
package). At present you can ask users to download the package themselves and
put it under /usr/portage/distfiles before proceeding. It may change in
(probably already near) future when licensing stuff is handled in portage.
George
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2002-04-18 6:13 Avi Schwartz
2002-04-18 6:59 ` George Shapovalov
@ 2002-04-18 7:15 ` Tod M Neidt
1 sibling, 0 replies; 56+ messages in thread
From: Tod M Neidt @ 2002-04-18 7:15 UTC (permalink / raw
To: gentoo-dev
Hi!
On Thu, 2002-04-18 at 01:13, Avi Schwartz wrote:
> I am trying to create an ebuild for wingide. I have couple of problems
> I trying to solve here:
>
> 1. The name of the archive is wingide-1.1.3-1.tar.gz. I tried to call
> the ebuild file wingide-1.1.3-1.ebuild but ebuild doesn't like it since
> it thinks there are two version numbers. So I changed the name to
> wingide-1.1.3-r1.ebuild and I am sticking the -1 in the code:
I would name the ebuild: wingide-1.1.3.1.ebuild
You then have two options:
1. Hardcode the actual tarball name, i.e.
MYP=${PN}-1.1.3-1
2. Munge ${P} for the same result, i.e.
#Grab least significant version number
LSV=${PV##*.)
#Grab the rest
MYPV=${PV%.*}
#add the lsv back on
MYPV=${MYPV}-${LSV}
MYP=${PN}-{MYPV}
There might be a more elegant munge, but that should work (although you
should test it if you use it)
Either way, use ${MYP} and ${MYPV} in the SRC_URI where you would
normally use ${P} and ${PV}.
Method number 2 (the munge) makes the ebuild version independent.
SRC_URI="ftp://ftp.wingide.com/pub/wingide/${PV}/${MYP}.tar.gz
ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/macro-bugfix-all-${MYPV}.tar etc"
SRC_URI="ftp://ftp.wingide.com/pub/wingide/${PV}/${P}-1.tar.gzftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/macro-bugfix-all-${PV}-1.tar ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/print-bugfix-all-${PV}-1.tar ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/reuse-app-instance-all-${PV}-1.tar"
>
> SRC_URI="ftp://ftp.wingide.com/pub/wingide/${PV}/${P}-1.tar.gzftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/macro-bugfix-all-${PV}-1.tar ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/print-bugfix-all-${PV}-1.tar ftp://ftp.wingide.com/pub/wingide/${PV}/bugfix/reuse-app-instance-all-${PV}-1.tar"
>
> Is this an acceptable practice? The problem with this is that if they
> come out with a -2 version, it will not be enough to rename the ebuild
> file (although the bug fix files are breaking this anyway).
>
> BTW, PV and ${D} are not documented in the developers HOWTO. What else
> is missing?
Please see 'man 5 ebuild', but note that the syntax of the ebuild
example is stale. Use /usr/portage/skel.ebuild as a syntax and style
example.
>
> 2. Wingide comes with its own installation program which can be
> controlled through the command line. When its archive is expanded, it
> creates a wingide-1.1.3-1 directory in which there is the installation
> program and the program files. Ho do I point to the installation
> program? I tried the following ${WORKDIR}/${P}-1/wing-install.py, is
> this correct?
>
> 3. The parameters it expects are the installation directory and binary
> directory:
>
> ${WORKDIR}/${P}-1/wing-install.py \
> --winghome ${D}/usr/lib/wingide \
> --bin-dir ${D}/usr/bin
>
> again, does this make sense?
I assume that this is in src_compile?
Set S=${WORKDIR}/${MYP}
When src_compile is called ${S} is the current working directory so
wing-install.py \
--winghome ${D}/usr/lib/wingide \
--bin-dir ${D}/usr/bin \
|| die
should be sufficient (i assume you don't need an obligatory 'python' in
front of wing-install.py)
>
> 4. Another problem I am having is that I see the following messages when
> doing the install:
>
> >>> Install wingide-1.1.3-r1 into
> /var/tmp/portage/wingide-1.1.3-r1/image/ category avi
>
> but when I look at the image directory I see that it didn't install a
> thing
Two guesses
1. you need an '=' after you flags above
2. The wing-install isn't smart enough to check if the directory exists
before trying to copy which doesn't tend to work very well, might need a
dodir /usr/lib/wingide
dodir /usr/bin
before trying to install
.
>
> 5. The last 3 files are archives that have to be extracted over the root
> installation directory which will be ${D}/usr/lib/wingide. Again, how
> does one achieve this?
I'm not follwing you :( Oh wait, are they patches? or something similiar
>
> 6. The compile stage extracts all 4 files while I realy want only the
> main file to be extracted since the other 3 need to be extracted over
> the installed file. Is there a way to control this? I tried to put my
> own code in src_compile(), but ebuild goes ahead and extracts the
> archives before executing my code
Without looking at the package myself, I would just be guessing probably
badly :) Ok are you talking about the other files sownloaded from
SRC_URI? If so, you probably want to perform this in the src_unpack
function which is executed before src_compile. again see 'man 5 ebuild'
.
>
> 7. When the wingide archive is extracted, besides the installation
> program there is another tar file extracted which containsall the files.
> Another possibility for the installation of the main wingide archive is
> to just extract this archive into ${D}/usr/lib. The question is, do I
> have to create ${D}/usr/lib if it doesn't exist yet or will ebuild do it
> for me?
see above
Hope that helps,
tod
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] ebuild question
@ 2002-07-26 14:54 John Matthews
0 siblings, 0 replies; 56+ messages in thread
From: John Matthews @ 2002-07-26 14:54 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]
I finally got a Crystal Space ebuild that I can deal with. Unf. there is
one step I need assistance with.
When issuing a "make install", the system looks at either the default
destination directory or the one you set. I've been trying
/usr/local/crystal and if I use that, then "make install" gets a sandbox
violation. If, however, I use ${D}/usr/local/crystal then it installs
but right before that step it rewrites the cs-config script (like
sdl-config, gtk-config, etc.) to say that the location of the CS libs
and headers is /var/tmp/portage/crystal-0.94-r2/image//usr/local/crystal
(or something like that, I don't have it in front of me right now). Of
course, that'll be a bogus location when the package is actually
installed.
Do I need to do some sed magic to fix that somehow, by twiddling with
the cs-config file that's been installed in the image? Or is there some
sort of standard clever way to get around this problem with
non-./configure-style packages?
Random other info:
Meanwhile, I'm still in a position where I can't build optimized builds
with gcc 3.x and I can't use assembler at all. I've been told that CS
requires a special version of nasm or something like that, but haven't
found a direct reference for what works yet. Building a debug build with
no assembler gets me a working install image, I believe, on gcc 3.x and
gcc 2.95.
Regards and thanks,
matt
--
Matt Matthews \ ph: 919.660.2811 \ Use GNU/Linux _o) w00t
Duke Univ., Postdoc\ jvmatthe@math.duke.edu \____________ /\\
Dept. of Mathematics\ http://www.math.duke.edu/~jvmatthe/ \ _\_V
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2002-11-26 21:27 Per Wigren
@ 2002-11-26 21:23 ` Dan Armak
2002-11-27 0:03 ` Per Wigren
0 siblings, 1 reply; 56+ messages in thread
From: Dan Armak @ 2002-11-26 21:23 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 26 November 2002 23:27, Per Wigren wrote:
> Hi!
>
> I'm making an ebuild for GOBO 3.0 (http://www.gobosoft.com), but I still
> have to finetune the install()-part of the ebuild... The problem is that it
> takes about 4 hours (!!) to compile, and everytime I make a small change it
> will rebuild the tmp-dir and recompile...
>
> How can I tell "ebuild install" that it should NOT do that? Just do the
> install-part without recompiling for another 4 hours, even if I just
> changed the ebuild...
Adding 'noauto' to FEATURES in make.conf should do that.
- --
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://www.gentoo.org/~danarmak/danarmak-gpg-public.key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE94+Y0UI2RQ41fiVERAh+sAJ0WeWXa6/UKzVoTA73OhgxAGMfZdACeO+11
0iKADHqMggUmade67gVO7bY=
=BQcb
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] ebuild question
@ 2002-11-26 21:27 Per Wigren
2002-11-26 21:23 ` Dan Armak
0 siblings, 1 reply; 56+ messages in thread
From: Per Wigren @ 2002-11-26 21:27 UTC (permalink / raw
To: gentoo-dev
Hi!
I'm making an ebuild for GOBO 3.0 (http://www.gobosoft.com), but I still have
to finetune the install()-part of the ebuild... The problem is that it takes
about 4 hours (!!) to compile, and everytime I make a small change it will
rebuild the tmp-dir and recompile...
How can I tell "ebuild install" that it should NOT do that? Just do the
install-part without recompiling for another 4 hours, even if I just changed
the ebuild...
Regards
Per Wigren
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2002-11-26 21:23 ` Dan Armak
@ 2002-11-27 0:03 ` Per Wigren
0 siblings, 0 replies; 56+ messages in thread
From: Per Wigren @ 2002-11-27 0:03 UTC (permalink / raw
To: danarmak, gentoo-dev
Tuesday 26 November 2002 22:23 skrev Dan Armak:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 26 November 2002 23:27, Per Wigren wrote:
> > Hi!
> >
> > I'm making an ebuild for GOBO 3.0 (http://www.gobosoft.com), but I still
> > have to finetune the install()-part of the ebuild... The problem is that
> > it takes about 4 hours (!!) to compile, and everytime I make a small
> > change it will rebuild the tmp-dir and recompile...
> >
> > How can I tell "ebuild install" that it should NOT do that? Just do the
> > install-part without recompiling for another 4 hours, even if I just
> > changed the ebuild...
>
> Adding 'noauto' to FEATURES in make.conf should do that.
Yes that's it! Thanks a lot!
// Per Wigren
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] ebuild question
@ 2003-05-30 11:15 MAL
2003-05-30 11:29 ` Alastair Tse
0 siblings, 1 reply; 56+ messages in thread
From: MAL @ 2003-05-30 11:15 UTC (permalink / raw
To: gentoo-dev
gucharmap didn't have an uptodate ebuild, so I thought I'd put one
together, but..
The configure/Makefile for gucharmap-0.6.1 attempts to rebuild the GTK
input module cache file during install. Obviously portage catches this,
so what's the best way to handle this?
It basically executes:
gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules
The possibilities I can see are:
a) possibly portage has a function to specify that access to
/etc/gtk-2.0/gtk.immodules is allowed.
or
b) I provide a patch to the sources to stop this happening, then do it
myself in the ebuild after install.
Any other ideas? What's best?
Cheers,
MAL
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-05-30 11:15 MAL
@ 2003-05-30 11:29 ` Alastair Tse
2003-05-30 14:22 ` MAL
0 siblings, 1 reply; 56+ messages in thread
From: Alastair Tse @ 2003-05-30 11:29 UTC (permalink / raw
To: MAL; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
On Fri, 2003-05-30 at 12:15, MAL wrote:
> a) possibly portage has a function to specify that access to
> /etc/gtk-2.0/gtk.immodules is allowed.
Thats a no no. Unless there is absolutely no way to patch that
behaviour.
> b) I provide a patch to the sources to stop this happening, then do it
> myself in the ebuild after install.
You have to patch that part out and make sure you can produce the same
effect during pkg_postinst() and also reverse the effect when you do
pkg_postrm() (if possible.) You need to test it pretty well to make sure
pkg_postinst() and pkg_postrm() works as expected, esp in regards
prefixing paths with ${ROOT} when writing files, etc.
Cheers,
Alastair
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-05-30 11:29 ` Alastair Tse
@ 2003-05-30 14:22 ` MAL
2003-05-30 14:33 ` Alastair Tse
2003-05-30 14:39 ` Seemant Kulleen
0 siblings, 2 replies; 56+ messages in thread
From: MAL @ 2003-05-30 14:22 UTC (permalink / raw
To: Alastair Tse; +Cc: gentoo-dev
Alastair Tse wrote:
> On Fri, 2003-05-30 at 12:15, MAL wrote:
>
>
>>a) possibly portage has a function to specify that access to
>>/etc/gtk-2.0/gtk.immodules is allowed.
>
>
> Thats a no no. Unless there is absolutely no way to patch that
> behaviour.
>
>
>>b) I provide a patch to the sources to stop this happening, then do it
>>myself in the ebuild after install.
>
>
> You have to patch that part out and make sure you can produce the same
> effect during pkg_postinst() and also reverse the effect when you do
> pkg_postrm() (if possible.) You need to test it pretty well to make sure
> pkg_postinst() and pkg_postrm() works as expected, esp in regards
> prefixing paths with ${ROOT} when writing files, etc.
Thanks for the info, see what you think:
http://bugs.gentoo.org/show_bug.cgi?id=21953
Is it better to upload an ebuild as a .tar.bz2 with digests, patches
etc. all included?
Cheers,
MAL
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-05-30 14:22 ` MAL
@ 2003-05-30 14:33 ` Alastair Tse
2003-05-30 14:40 ` Todd Berman
2003-05-30 14:39 ` Seemant Kulleen
1 sibling, 1 reply; 56+ messages in thread
From: Alastair Tse @ 2003-05-30 14:33 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
On Fri, 2003-05-30 at 15:22, MAL wrote:
> Is it better to upload an ebuild as a .tar.bz2 with digests, patches
> etc. all included?
Ebuilds should not be attached as tar.bz2, they should be in text/plain.
It's actually written in the Ebuils Contribution Guide somewhere, and
also one of the most common problems with ebuild submission as I listed
in my ebuild mistakes list
(http://cvs.gentoo.org/~liquidx/ebuildmistakes.html).
Cheers,
--
Alastair 'liquidx' Tse
>> Gentoo Developer
>> http://www.liquidx.net/ | http://cvs.gentoo.org/~liquidx/
>> GPG Key : http://cvs.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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-05-30 14:22 ` MAL
2003-05-30 14:33 ` Alastair Tse
@ 2003-05-30 14:39 ` Seemant Kulleen
2003-05-30 15:09 ` Seemant Kulleen
1 sibling, 1 reply; 56+ messages in thread
From: Seemant Kulleen @ 2003-05-30 14:39 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 485 bytes --]
> Is it better to upload an ebuild as a .tar.bz2 with digests, patches
> etc. all included?
>
> Cheers,
> MAL
Yes, except for the digests. No self-respecting dev would simply add a submitted digest (no offence to you, personally).
--
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux http://www.gentoo.org/~seemant
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-05-30 14:33 ` Alastair Tse
@ 2003-05-30 14:40 ` Todd Berman
2003-05-30 14:55 ` Jon Portnoy
0 siblings, 1 reply; 56+ messages in thread
From: Todd Berman @ 2003-05-30 14:40 UTC (permalink / raw
To: gentoo-dev
Not to generate useless traffic, but I feel it is very important to
reiterate this.
Please, please, please attach your ebuilds to bugzilla as text/plain and
as single files. Two common errors I have seen plenty are attaching a
.tar.gz or .tar.bz2, or, and more of a problem for me, are the text
files attached, but set as an octet stream so the viewer wont kick in.
This cant be stressed enough as the 'proper' way to submit an ebuild if
you want to see it committed as fast as possible.
And as an aside, maybe zhen or whoever maintains bugs.g.o can set
text/plain as the default file upload, because i assume plenty of people
just forget to change it.
--Todd
On Fri, 2003-05-30 at 10:33, Alastair Tse wrote:
> On Fri, 2003-05-30 at 15:22, MAL wrote:
> > Is it better to upload an ebuild as a .tar.bz2 with digests, patches
> > etc. all included?
>
> Ebuilds should not be attached as tar.bz2, they should be in text/plain.
> It's actually written in the Ebuils Contribution Guide somewhere, and
> also one of the most common problems with ebuild submission as I listed
> in my ebuild mistakes list
> (http://cvs.gentoo.org/~liquidx/ebuildmistakes.html).
>
> Cheers,
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-05-30 14:40 ` Todd Berman
@ 2003-05-30 14:55 ` Jon Portnoy
2003-05-30 15:08 ` MAL
0 siblings, 1 reply; 56+ messages in thread
From: Jon Portnoy @ 2003-05-30 14:55 UTC (permalink / raw
To: Todd Berman; +Cc: gentoo-dev
On Fri, May 30, 2003 at 10:40:09AM -0400, Todd Berman wrote:
> Not to generate useless traffic, but I feel it is very important to
> reiterate this.
>
> Please, please, please attach your ebuilds to bugzilla as text/plain and
> as single files. Two common errors I have seen plenty are attaching a
> .tar.gz or .tar.bz2, or, and more of a problem for me, are the text
> files attached, but set as an octet stream so the viewer wont kick in.
>
> This cant be stressed enough as the 'proper' way to submit an ebuild if
> you want to see it committed as fast as possible.
>
> And as an aside, maybe zhen or whoever maintains bugs.g.o can set
> text/plain as the default file upload, because i assume plenty of people
> just forget to change it.
>
> --Todd
>
> On Fri, 2003-05-30 at 10:33, Alastair Tse wrote:
> > On Fri, 2003-05-30 at 15:22, MAL wrote:
> > > Is it better to upload an ebuild as a .tar.bz2 with digests, patches
> > > etc. all included?
> >
> > Ebuilds should not be attached as tar.bz2, they should be in text/plain.
> > It's actually written in the Ebuils Contribution Guide somewhere, and
> > also one of the most common problems with ebuild submission as I listed
> > in my ebuild mistakes list
> > (http://cvs.gentoo.org/~liquidx/ebuildmistakes.html).
> >
> > Cheers,
>
>
Just to throw in a "me too" - it drives me absolutely nuts when people
don't submit ebuilds as plain text. Patches et al should also be plain
text. It's much easier for me to review it that way and will definitely
get your ebuild processed faster.
--
Jon Portnoy
avenj/irc.freenode.net
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-05-30 14:55 ` Jon Portnoy
@ 2003-05-30 15:08 ` MAL
0 siblings, 0 replies; 56+ messages in thread
From: MAL @ 2003-05-30 15:08 UTC (permalink / raw
To: gentoo-dev; +Cc: Jon Portnoy, tberman
Jon Portnoy wrote:
> On Fri, May 30, 2003 at 10:40:09AM -0400, Todd Berman wrote:
>
>>Not to generate useless traffic, but I feel it is very important to
>>reiterate this.
>>
>>Please, please, please attach your ebuilds to bugzilla as text/plain and
>>as single files. Two common errors I have seen plenty are attaching a
>>.tar.gz or .tar.bz2, or, and more of a problem for me, are the text
>>files attached, but set as an octet stream so the viewer wont kick in.
>>
>>This cant be stressed enough as the 'proper' way to submit an ebuild if
>>you want to see it committed as fast as possible.
>>
>>And as an aside, maybe zhen or whoever maintains bugs.g.o can set
>>text/plain as the default file upload, because i assume plenty of people
>>just forget to change it.
>
> Just to throw in a "me too" - it drives me absolutely nuts when people
> don't submit ebuilds as plain text. Patches et al should also be plain
> text. It's much easier for me to review it that way and will definitely
> get your ebuild processed faster.
ok ok people.. if you look at the bug, you'll see that I submitted them
as text, and set the mime type too... I just then wondered if people
liked to see a .tar.bz2 _as well_
Has anyone actually looked at the ebuild yet? :p
It's my first submission and I'd like to know if I've gone about it the
right way, (in regards to updating the gtk2 input module cache).
Cheers ppl,
MAL
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-05-30 14:39 ` Seemant Kulleen
@ 2003-05-30 15:09 ` Seemant Kulleen
0 siblings, 0 replies; 56+ messages in thread
From: Seemant Kulleen @ 2003-05-30 15:09 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]
On Fri, 30 May 2003 07:39:49 -0700
Seemant Kulleen <seemant@gentoo.org> wrote:
>
> > Is it better to upload an ebuild as a .tar.bz2 with digests, patches
> > etc. all included?
> >
> > Cheers,
> > MAL
>
>
> Yes, except for the digests. No self-respecting dev would simply add a submitted digest (no offence to you, personally).
Sorry, not to be misleading -- don't attach tarballs, and don't attach digests. Tarballs are annoying, digests are useless.
--
Seemant Kulleen
Developer and Project Co-ordinator,
Gentoo Linux http://www.gentoo.org/~seemant
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] ebuild question
@ 2003-05-30 15:17 William Hubbs
2003-05-30 15:27 ` Grant Goodyear
0 siblings, 1 reply; 56+ messages in thread
From: William Hubbs @ 2003-05-30 15:17 UTC (permalink / raw
To: Gentoo Developers
Hi all,
I am working on an ebuild for sus ( http://pdg.uow.edu.au/sus/).
This program doesn't use autoconf. It just has a makefile which must be edited to set up the locations files should be installed. What is the best way to handle this? I can think of two options -- use sed to edit the file, or generate a patch.
Thanks,
William
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-05-30 15:17 William Hubbs
@ 2003-05-30 15:27 ` Grant Goodyear
2003-05-31 3:00 ` Georgi Georgiev
0 siblings, 1 reply; 56+ messages in thread
From: Grant Goodyear @ 2003-05-30 15:27 UTC (permalink / raw
To: Gentoo Developers
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
On Fri, 2003-05-30 at 11:17, William Hubbs wrote:
> Hi all,
>
> I am working on an ebuild for sus ( http://pdg.uow.edu.au/sus/).
>
> This program doesn't use autoconf. It just has a makefile which must be edited to set up the locations files should be installed. What is the best way to handle this? I can think of two options -- use sed to edit the file, or generate a patch.
A patch is one more file that you have to maintain, so sed is generally
preferred if it's not too ugly.
-g2boojum-
--
Grant Goodyear <g2boojum@gentoo.org>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-05-30 15:27 ` Grant Goodyear
@ 2003-05-31 3:00 ` Georgi Georgiev
0 siblings, 0 replies; 56+ messages in thread
From: Georgi Georgiev @ 2003-05-31 3:00 UTC (permalink / raw
To: Gentoo Developers
On 30/05/2003 at 11:27:21(-0400), Grant Goodyear used 1.0Kbytes just to say:
> On Fri, 2003-05-30 at 11:17, William Hubbs wrote:
> > Hi all,
> >
> > I am working on an ebuild for sus ( http://pdg.uow.edu.au/sus/).
> >
> > This program doesn't use autoconf. It just has a makefile which must be
> > edited to set up the locations files should be installed. What is the best
> > way to handle this? I can think of two options -- use sed to edit the
> > file, or generate a patch.
>
> A patch is one more file that you have to maintain, so sed is generally
> preferred if it's not too ugly.
Maybe it would be easy enough to set the necessary makefile macros on the
command-line. i.e.
make PREFIX="$D" CFLAGS="...."
etc.
--
/^^^^^^^^^^^^^^^^^^^^^^^^^^^\/^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\
/ Georgi Georgiev (-< / Computer programmers do it byte \
\ chutz@chubaka.net /\ .o)\ by byte. /
/ +81(90)6266-1163 V_/_ |(/)/ \
\___________________________/\__________________________________/
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] ebuild question
@ 2003-06-10 14:25 MAL
2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
2003-06-12 11:34 ` [gentoo-dev] ebuild question Amiel Martin
0 siblings, 2 replies; 56+ messages in thread
From: MAL @ 2003-06-10 14:25 UTC (permalink / raw
To: gentoo-dev
I'm writing an ebuild for ZoneMinder, and I have a few problems/queries..
The program is a bunch of php and a few cgi apps. After configuring,
the package asks you to run a perl script which interactively asks you
for initial configuration, then updates the .php files with this info.
'make install' then installs the .php files into your document root,
(and the cgi into your cgi-bin dir).
Now, I don't want to break the non-interactivity of portage, but I can't
just leave an 'einfo' message to the user after install, asking them to
run the perl script, because this must be done before install.
So, do I either:
* Use expect to answer the perl script's questions with some sensible
defaults, then leave a message to the user on how to change these
defaults after install, (in which case, should I add expect to the
DEPEND line?)
* Re-package the software entirely, (there is a compiled part and a
non-compiled php part.. maybe separate the php part out). I'm kinda
loathed to do this, as it seems like unnecessary maintenance.
* Modify the perl script to automatically set certain defaults.
Additionally, what do I do about the location of apache, and the
user/group to set the php files as? :)
I noticed the recent eclass submission, but I'm assuming I can't use
that just yet, so /home/httpd/htdocs and apache:apache ?
Cheers,
MAL
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] A nice idea to improve portage
2003-06-10 14:25 [gentoo-dev] ebuild question MAL
@ 2003-06-10 15:40 ` MooktaKiNG
2003-06-10 16:07 ` Matthew Kennedy
` (2 more replies)
2003-06-12 11:34 ` [gentoo-dev] ebuild question Amiel Martin
1 sibling, 3 replies; 56+ messages in thread
From: MooktaKiNG @ 2003-06-10 15:40 UTC (permalink / raw
To: gentoo-dev
I think it would be better if portage included a README file for
each ebuild.
This i belive is very important becuase gentoo is a bit different
from a normal linux.
Like when installing a mod_php you run the command:
ebuild .../mod_php config
after installtion.
See when i installed this first i had know idea.
I know i know. there are some text at the end of the emerge that
says what you should do.
But when your doind multiple emerge's one after the other and you
leave gentoo todo its thing. You don't see the text.
So if there was a nice README file that explain the 'extra' setting
needed on each dir in portage then it would make things a LOT easier
and would be very helpful.
If this already exists please ignore this email.
-------------------------------------------------
Please wait while you are redirected to my signature......
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] A nice idea to improve portage
2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
@ 2003-06-10 16:07 ` Matthew Kennedy
2003-06-10 18:05 ` John Robinson
2003-06-11 11:52 ` [gentoo-dev] Readme files for portage (was: A nice idea to improve portage) Svyatogor
2 siblings, 0 replies; 56+ messages in thread
From: Matthew Kennedy @ 2003-06-10 16:07 UTC (permalink / raw
To: gentoo-dev
"MooktaKiNG" <Mooktakim@hotmail.com> writes:
> I think it would be better if portage included a README file for
> each ebuild.
>
I think this is a good idea. Many ebuilds already include a
REAME.Gentoo which contains extra information. Its possible that
this is not used consistently though.
Matt
--
Matthew Kennedy
Gentoo Linux Developer
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] A nice idea to improve portage
2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
2003-06-10 16:07 ` Matthew Kennedy
@ 2003-06-10 18:05 ` John Robinson
2003-06-10 20:20 ` Philippe Lafoucrière
2003-06-10 21:56 ` MooktaKiNG
2003-06-11 11:52 ` [gentoo-dev] Readme files for portage (was: A nice idea to improve portage) Svyatogor
2 siblings, 2 replies; 56+ messages in thread
From: John Robinson @ 2003-06-10 18:05 UTC (permalink / raw
To: gentoo-dev
> I know i know. there are some text at the end of the emerge that
> says what you should do.
>
> But when your doind multiple emerge's one after the other and you
> leave gentoo todo its thing. You don't see the text.
>
> So if there was a nice README file that explain the 'extra' setting
> needed on each dir in portage then it would make things a LOT easier
> and would be very helpful.
Honestly, I think I'd much prefer if portage just queued all of those
messages and displayed them at the end of the emerge. If that
information was in a README, you'd have to go, find, and read the README
for every package and dependency that you install. That's a lot of work.
Since portage is supposed to be non-interactive, it shouldn't assume
that you're gonna stick around watching the terminal while it does its
thing. ;)
- John
--
Love justice; desire mercy.
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] A nice idea to improve portage
2003-06-10 18:05 ` John Robinson
@ 2003-06-10 20:20 ` Philippe Lafoucrière
2003-06-11 3:18 ` Luke Graham
2003-06-10 21:56 ` MooktaKiNG
1 sibling, 1 reply; 56+ messages in thread
From: Philippe Lafoucrière @ 2003-06-10 20:20 UTC (permalink / raw
To: strider; +Cc: gentoo-dev
> Honestly, I think I'd much prefer if portage just queued all of those
> messages and displayed them at the end of the emerge. If that
> information was in a README, you'd have to go, find, and read the README
> for every package and dependency that you install. That's a lot of work.
> Since portage is supposed to be non-interactive, it shouldn't assume
> that you're gonna stick around watching the terminal while it does its
> thing. ;)
Hmmm both are good ideas !! Why don't add some README files, that are displayed
(instead of queued) at the end of an emerge ?
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] A nice idea to improve portage
2003-06-10 21:56 ` MooktaKiNG
@ 2003-06-10 21:42 ` Zach Forrest
2003-06-10 23:26 ` Kumba
0 siblings, 1 reply; 56+ messages in thread
From: Zach Forrest @ 2003-06-10 21:42 UTC (permalink / raw
To: gentoo-dev
You could also have "logmessages" FEATURE (in make.conf) that, if
enabled, logged the output of einfo, etc.
MooktaKiNG wrote:
> But i usually start an emerge and then do && halt
>
> This shutsdown gentoo after the emerge.
>
> Its still the same problem.
>
> But why can't we have both?
>
> A readme should not me too hard. The person who makes the actual
> ebuild just types a small README to explain stuff. Thats all.
>
>
>
>>>I know i know. there are some text at the end of the emerge that
>>>says what you should do.
>>>
>>>But when your doind multiple emerge's one after the other and you
>>>leave gentoo todo its thing. You don't see the text.
>>>
>>>So if there was a nice README file that explain the 'extra'
>>>setting
>>>needed on each dir in portage then it would make things a LOT
>>>easier
>>>and would be very helpful.
>>
>>Honestly, I think I'd much prefer if portage just queued all of
>>those
>>messages and displayed them at the end of the emerge. If that
>>information was in a README, you'd have to go, find, and read the
>>README
>>for every package and dependency that you install. That's a lot of
>>work.
>>Since portage is supposed to be non-interactive, it shouldn't assume
>>that you're gonna stick around watching the terminal while it does
>>its
>>thing. ;)
>>
>>- John
>>
>>--
>>
>>Love justice; desire mercy.
>>
>>
>>--
>>gentoo-dev@gentoo.org mailing list
>>
>>
>
>
>
> -------------------------------------------------
> Please wait while you are redirected to my signature......
>
> --
> gentoo-dev@gentoo.org mailing list
>
>
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] A nice idea to improve portage
2003-06-10 18:05 ` John Robinson
2003-06-10 20:20 ` Philippe Lafoucrière
@ 2003-06-10 21:56 ` MooktaKiNG
2003-06-10 21:42 ` Zach Forrest
1 sibling, 1 reply; 56+ messages in thread
From: MooktaKiNG @ 2003-06-10 21:56 UTC (permalink / raw
To: gentoo-dev
But i usually start an emerge and then do && halt
This shutsdown gentoo after the emerge.
Its still the same problem.
But why can't we have both?
A readme should not me too hard. The person who makes the actual
ebuild just types a small README to explain stuff. Thats all.
>> I know i know. there are some text at the end of the emerge that
>> says what you should do.
>>
>> But when your doind multiple emerge's one after the other and you
>> leave gentoo todo its thing. You don't see the text.
>>
>> So if there was a nice README file that explain the 'extra'
>> setting
>> needed on each dir in portage then it would make things a LOT
>> easier
>> and would be very helpful.
>
> Honestly, I think I'd much prefer if portage just queued all of
> those
> messages and displayed them at the end of the emerge. If that
> information was in a README, you'd have to go, find, and read the
> README
> for every package and dependency that you install. That's a lot of
> work.
> Since portage is supposed to be non-interactive, it shouldn't assume
> that you're gonna stick around watching the terminal while it does
> its
> thing. ;)
>
> - John
>
> --
>
> Love justice; desire mercy.
>
>
> --
> gentoo-dev@gentoo.org mailing list
>
>
-------------------------------------------------
Please wait while you are redirected to my signature......
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] A nice idea to improve portage
2003-06-10 21:42 ` Zach Forrest
@ 2003-06-10 23:26 ` Kumba
0 siblings, 0 replies; 56+ messages in thread
From: Kumba @ 2003-06-10 23:26 UTC (permalink / raw
To: Zach Forrest; +Cc: gentoo-dev
Zach Forrest wrote:
> You could also have "logmessages" FEATURE (in make.conf) that, if
> enabled, logged the output of einfo, etc.
Actually, this feature already exists. If PORT_LOGDIR is defined to a
location in /etc/make.conf, then portage will log all output to the
specified location.
--Kumba
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] A nice idea to improve portage
2003-06-10 20:20 ` Philippe Lafoucrière
@ 2003-06-11 3:18 ` Luke Graham
2003-06-11 5:10 ` Bill Kenworthy
0 siblings, 1 reply; 56+ messages in thread
From: Luke Graham @ 2003-06-11 3:18 UTC (permalink / raw
To: gentoo-dev
On Wed, 11 Jun 2003 06:20 am, Philippe Lafoucrière wrote:
> > Honestly, I think I'd much prefer if portage just queued all of those
> > messages and displayed them at the end of the emerge. If that
> > information was in a README, you'd have to go, find, and read the README
> > for every package and dependency that you install. That's a lot of work.
> > Since portage is supposed to be non-interactive, it shouldn't assume
> > that you're gonna stick around watching the terminal while it does its
> > thing. ;)
>
> Hmmm both are good ideas !! Why don't add some README files, that are
> displayed (instead of queued) at the end of an emerge ?
emerge <stuff> >output 2>&1
less output
--
luke
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] A nice idea to improve portage
2003-06-11 3:18 ` Luke Graham
@ 2003-06-11 5:10 ` Bill Kenworthy
0 siblings, 0 replies; 56+ messages in thread
From: Bill Kenworthy @ 2003-06-11 5:10 UTC (permalink / raw
To: Luke Graham; +Cc: list gentoo-dev
Have them added to /var/log/emerge.log so they are there for posterity
as well ... I think this would be a great enhancement.
BillK
On Wed, 2003-06-11 at 11:18, Luke Graham wrote:
> On Wed, 11 Jun 2003 06:20 am, Philippe Lafoucrière wrote:
> > > Honestly, I think I'd much prefer if portage just queued all of those
> > > messages and displayed them at the end of the emerge. If that
> > > information was in a README, you'd have to go, find, and read the README
> > > for every package and dependency that you install. That's a lot of work.
> > > Since portage is supposed to be non-interactive, it shouldn't assume
> > > that you're gonna stick around watching the terminal while it does its
> > > thing. ;)
> >
> > Hmmm both are good ideas !! Why don't add some README files, that are
> > displayed (instead of queued) at the end of an emerge ?
>
> emerge <stuff> >output 2>&1
> less output
--
Bill Kenworthy <billk@iinet.net.au>
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)
2003-06-11 10:37 ` MooktaKiNG
@ 2003-06-11 10:10 ` Michael Cummings
2003-06-11 10:44 ` Paul de Vrieze
` (2 more replies)
0 siblings, 3 replies; 56+ messages in thread
From: Michael Cummings @ 2003-06-11 10:10 UTC (permalink / raw
To: MooktaKiNG; +Cc: gentoo-dev
On Wed, Jun 11, 2003 at 11:37:02AM +0100, MooktaKiNG wrote:
> Another good reason to have a README is becuase sometimes people
> want to know more about a program. Without having to install it.
>
> If they can learn about the program before they install. They are
> more aware of how hard/easy the installtion is.
I thought that was one of the reasons the source URL shows up in a
search. It's how I've always checked to see what a package does. README
files, imo, are great in theory but put additional maintenance strain on
a dev. Just my two euros,
Mike
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)
2003-06-11 11:52 ` [gentoo-dev] Readme files for portage (was: A nice idea to improve portage) Svyatogor
@ 2003-06-11 10:37 ` MooktaKiNG
2003-06-11 10:10 ` Michael Cummings
0 siblings, 1 reply; 56+ messages in thread
From: MooktaKiNG @ 2003-06-11 10:37 UTC (permalink / raw
To: gentoo-dev
Another good reason to have a README is becuase sometimes people
want to know more about a program. Without having to install it.
If they can learn about the program before they install. They are
more aware of how hard/easy the installtion is.
Or when your trying to help someone. You don't know what that
program does. You read the README. Then you get someidea. Now your
in a much better position to help then before.
> I think it's a greÁt idea. Unfortunately most discussion till now
> was around outputing
> the the info to some log and so on. However the suggestion (which I
> was going to
> make anyway) is much broader. The only pease of information portage
> helds about
> every package is a short description line.
>
> That's ok, if you know what the package does. Know imagine a
> situation when you
> do emerge --pretend something and you get a list packages, some of
> which you have
> no idea about. It would be very useful if you could read a readme
> file for them to see
> what they are actually doing.
>
> Having a readme would also be very useful in many other cases, when
> you want to get
> some info on the package, without going to their web site.
>
> On Tue, 10 Jun 2003 16:40:12 +0100 (BST)
> "MooktaKiNG" <Mooktakim@hotmail.com> wrote:
>
>> I think it would be better if portage included a README file for
>> each ebuild.
>>
>> This i belive is very important becuase gentoo is a bit different
>> from a normal linux.
>>
>> Like when installing a mod_php you run the command:
>>
>> ebuild .../mod_php config
>>
>> after installtion.
>>
>> See when i installed this first i had know idea.
>>
>> I know i know. there are some text at the end of the emerge that
>> says what you should do.
>>
>> But when your doind multiple emerge's one after the other and you
>> leave gentoo todo its thing. You don't see the text.
>>
>> So if there was a nice README file that explain the 'extra'
>> setting
>> needed on each dir in portage then it would make things a LOT
>> easier
>> and would be very helpful.
>>
>> If this already exists please ignore this email.
>>
>> -------------------------------------------------
>> Please wait while you are redirected to my signature......
>>
>> --
>> gentoo-dev@gentoo.org mailing list
>>
>>
>
>
> --
> Sergey Kuleshov <svyatogor@gentoo.org>
> Let the Force be with us!
>
> --
> gentoo-dev@gentoo.org mailing list
>
>
-------------------------------------------------
Please wait while you are redirected to my signature......
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)
2003-06-11 10:10 ` Michael Cummings
@ 2003-06-11 10:44 ` Paul de Vrieze
2003-06-11 13:24 ` [gentoo-dev] " D. Tuinstra
2003-06-11 17:06 ` [gentoo-dev] " MooktaKiNG
2 siblings, 0 replies; 56+ messages in thread
From: Paul de Vrieze @ 2003-06-11 10:44 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 889 bytes --]
On Wednesday 11 June 2003 12:10, Michael Cummings wrote:
> On Wed, Jun 11, 2003 at 11:37:02AM +0100, MooktaKiNG wrote:
> > Another good reason to have a README is becuase sometimes people
> > want to know more about a program. Without having to install it.
> >
> > If they can learn about the program before they install. They are
> > more aware of how hard/easy the installtion is.
>
> I thought that was one of the reasons the source URL shows up in a
> search. It's how I've always checked to see what a package does. README
> files, imo, are great in theory but put additional maintenance strain on
> a dev. Just my two euros,
>
Most probably the upcomming herds system will introduce a metadata file that
also includes the possibility for a long description.
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 --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)
2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
2003-06-10 16:07 ` Matthew Kennedy
2003-06-10 18:05 ` John Robinson
@ 2003-06-11 11:52 ` Svyatogor
2003-06-11 10:37 ` MooktaKiNG
2 siblings, 1 reply; 56+ messages in thread
From: Svyatogor @ 2003-06-11 11:52 UTC (permalink / raw
To: gentoo-dev
I think it's a greаt idea. Unfortunately most discussion till now was around outputing
the the info to some log and so on. However the suggestion (which I was going to
make anyway) is much broader. The only pease of information portage helds about
every package is a short description line.
That's ok, if you know what the package does. Know imagine a situation when you
do emerge --pretend something and you get a list packages, some of which you have
no idea about. It would be very useful if you could read a readme file for them to see
what they are actually doing.
Having a readme would also be very useful in many other cases, when you want to get
some info on the package, without going to their web site.
On Tue, 10 Jun 2003 16:40:12 +0100 (BST)
"MooktaKiNG" <Mooktakim@hotmail.com> wrote:
> I think it would be better if portage included a README file for
> each ebuild.
>
> This i belive is very important becuase gentoo is a bit different
> from a normal linux.
>
> Like when installing a mod_php you run the command:
>
> ebuild .../mod_php config
>
> after installtion.
>
> See when i installed this first i had know idea.
>
> I know i know. there are some text at the end of the emerge that
> says what you should do.
>
> But when your doind multiple emerge's one after the other and you
> leave gentoo todo its thing. You don't see the text.
>
> So if there was a nice README file that explain the 'extra' setting
> needed on each dir in portage then it would make things a LOT easier
> and would be very helpful.
>
> If this already exists please ignore this email.
>
> -------------------------------------------------
> Please wait while you are redirected to my signature......
>
> --
> gentoo-dev@gentoo.org mailing list
>
>
--
Sergey Kuleshov <svyatogor@gentoo.org>
Let the Force be with us!
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] Re: Readme files for portage (was: A nice idea to improve portage)
2003-06-11 10:10 ` Michael Cummings
2003-06-11 10:44 ` Paul de Vrieze
@ 2003-06-11 13:24 ` D. Tuinstra
2003-06-11 15:47 ` oford
2003-06-11 17:06 ` [gentoo-dev] " MooktaKiNG
2 siblings, 1 reply; 56+ messages in thread
From: D. Tuinstra @ 2003-06-11 13:24 UTC (permalink / raw
To: gentoo-dev
Michael Cummings wrote:
> On Wed, Jun 11, 2003 at 11:37:02AM +0100, MooktaKiNG wrote:
>> Another good reason to have a README is becuase sometimes people
>> want to know more about a program. Without having to install it.
>>
>> If they can learn about the program before they install. They are
>> more aware of how hard/easy the installtion is.
>
> I thought that was one of the reasons the source URL shows up in a
> search. It's how I've always checked to see what a package does.
> README files, imo, are great in theory but put additional
> maintenance strain on a dev. Just my two euros,
>
> Mike
As I see the original proposal, it was to give users essential
post-install information regarding any further steps they need to
take. This kind of information is different from pre-emerge info
that a user uses to decide the desirability of a package.
Pre-emerge info
---------------
Still, a small README could be valuable in some situations. For
example: "This package is included in portage for backwards
compatability for systems that have to interoperate with
MegaCruft's General Ledger FPS. If you don't have to do this you
may wish to consider <KDE-alternate> or <GNOME-alternate>. They
provide the same features within a modern UI, don't hog the CPU,
and don't require you to do manual post-emerge steps. And BTW, the
official site is a pathetic mass of marketing-speak, go to the
user-group page at <URL> instead." This shouldn't be too much of a
dev burden if it's optional and intended to communicate info that
wouldn't be found on an official web page.
A pre-emerge README feature runs the risk of encouraging
editorializing (as above :-), but hey, as long as its kept
reasonable that's part of the fun.
Post-emerge info
----------------
I'm all for it. My wish list: append each package's message to a
file named something like "emerge_messages_<timestamp>". These
would be stored in a standard location relative to the user running
emerge. At the end of the emerge, if the file is empty portage
deletes it and no mention is made of it. If the file is nonempty,
portage displays a standard message directing the user to read it.
Two new emerge commands: 'einfomsg' to write a string to the message
file; 'einfocat' to cat a file to it.
Messages written to the file should be no more than ~25 lines of
text each, with some standard header (e.g., line of dashes, ebuild
name, line of dashes). If 25 lines isn't enough room, the message
should direct the user to more instructions in
/usr/share/doc/<package>.
--Dwight Tuinstra
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] Re: Readme files for portage (was: A nice idea to improve portage)
2003-06-11 13:24 ` [gentoo-dev] " D. Tuinstra
@ 2003-06-11 15:47 ` oford
0 siblings, 0 replies; 56+ messages in thread
From: oford @ 2003-06-11 15:47 UTC (permalink / raw
To: D. Tuinstra; +Cc: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2928 bytes --]
On Wed, 2003-06-11 at 08:24, D. Tuinstra wrote:
> Michael Cummings wrote:
>
> > On Wed, Jun 11, 2003 at 11:37:02AM +0100, MooktaKiNG wrote:
> >> Another good reason to have a README is becuase sometimes people
> >> want to know more about a program. Without having to install it.
> >>
> >> If they can learn about the program before they install. They are
> >> more aware of how hard/easy the installtion is.
> >
> > I thought that was one of the reasons the source URL shows up in a
> > search. It's how I've always checked to see what a package does.
> > README files, imo, are great in theory but put additional
> > maintenance strain on a dev. Just my two euros,
> >
> > Mike
>
> As I see the original proposal, it was to give users essential
> post-install information regarding any further steps they need to
> take. This kind of information is different from pre-emerge info
> that a user uses to decide the desirability of a package.
>
> Pre-emerge info
> ---------------
> Still, a small README could be valuable in some situations. For
> example: "This package is included in portage for backwards
> compatability for systems that have to interoperate with
> MegaCruft's General Ledger FPS. If you don't have to do this you
> may wish to consider <KDE-alternate> or <GNOME-alternate>. They
> provide the same features within a modern UI, don't hog the CPU,
> and don't require you to do manual post-emerge steps. And BTW, the
> official site is a pathetic mass of marketing-speak, go to the
> user-group page at <URL> instead." This shouldn't be too much of a
> dev burden if it's optional and intended to communicate info that
> wouldn't be found on an official web page.
>
> A pre-emerge README feature runs the risk of encouraging
> editorializing (as above :-), but hey, as long as its kept
> reasonable that's part of the fun.
>
> Post-emerge info
> ----------------
> I'm all for it. My wish list: append each package's message to a
> file named something like "emerge_messages_<timestamp>". These
> would be stored in a standard location relative to the user running
> emerge. At the end of the emerge, if the file is empty portage
> deletes it and no mention is made of it. If the file is nonempty,
> portage displays a standard message directing the user to read it.
>
> Two new emerge commands: 'einfomsg' to write a string to the message
> file; 'einfocat' to cat a file to it.
>
> Messages written to the file should be no more than ~25 lines of
> text each, with some standard header (e.g., line of dashes, ebuild
> name, line of dashes). If 25 lines isn't enough room, the message
> should direct the user to more instructions in
> /usr/share/doc/<package>.
It should also state which ebuild it belongs to in a very prominent
place. I know it sounds obvious but that kind of detail is important :)
--
Owen Ford <oford@ev1.net>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)
2003-06-11 10:10 ` Michael Cummings
2003-06-11 10:44 ` Paul de Vrieze
2003-06-11 13:24 ` [gentoo-dev] " D. Tuinstra
@ 2003-06-11 17:06 ` MooktaKiNG
2 siblings, 0 replies; 56+ messages in thread
From: MooktaKiNG @ 2003-06-11 17:06 UTC (permalink / raw
To: gentoo-dev
the URL is a great info to have. However some program have been
modified to suite gentoo. and this is the reason why i think there
should be a readme.
I don't think it too much extra work.
If you think about it. It's just a small portion of the time it
takes to make the actual ebuild.
I do appreciate what people do here, building ebuils and all.
I haven't does this yet. Gonna try to make one in the future i hope.
> On Wed, Jun 11, 2003 at 11:37:02AM +0100, MooktaKiNG wrote:
>> Another good reason to have a README is becuase sometimes people
>> want to know more about a program. Without having to install it.
>>
>> If they can learn about the program before they install. They are
>> more aware of how hard/easy the installtion is.
>
> I thought that was one of the reasons the source URL shows up in a
> search. It's how I've always checked to see what a package does.
> README
> files, imo, are great in theory but put additional maintenance
> strain on
> a dev. Just my two euros,
>
> Mike
>
> --
> gentoo-dev@gentoo.org mailing list
>
>
-------------------------------------------------
Please wait while you are redirected to my signature......
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-06-10 14:25 [gentoo-dev] ebuild question MAL
2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
@ 2003-06-12 11:34 ` Amiel Martin
1 sibling, 0 replies; 56+ messages in thread
From: Amiel Martin @ 2003-06-12 11:34 UTC (permalink / raw
To: MAL; +Cc: gentoo-dev
What Ive seen in other ebuilds is a file with the default options
that just gets sent to the "interactive setup script via stin. (ie no need
for expect)
take a look at /usr/portage/app-games/freecraft/freecraft-1.18.ebuild
and /usr/portage/app-games/freecraft/files/setup.input
cat ${FILESDIR}/setup.input | ./setup || die "setup failed"
nothing offical, just my observations
-AMiel
On Tue, 10 Jun 2003, MAL wrote:
I'm writing an ebuild for ZoneMinder, and I have a few problems/queries..
The program is a bunch of php and a few cgi apps. After configuring,
the package asks you to run a perl script which interactively asks you
for initial configuration, then updates the .php files with this info.
'make install' then installs the .php files into your document root,
(and the cgi into your cgi-bin dir).
Now, I don't want to break the non-interactivity of portage, but I can't
just leave an 'einfo' message to the user after install, asking them to
run the perl script, because this must be done before install.
So, do I either:
* Use expect to answer the perl script's questions with some sensible
defaults, then leave a message to the user on how to change these
defaults after install, (in which case, should I add expect to the
DEPEND line?)
* Re-package the software entirely, (there is a compiled part and a
non-compiled php part.. maybe separate the php part out). I'm kinda
loathed to do this, as it seems like unnecessary maintenance.
* Modify the perl script to automatically set certain defaults.
Additionally, what do I do about the location of apache, and the
user/group to set the php files as? :)
I noticed the recent eclass submission, but I'm assuming I can't use
that just yet, so /home/httpd/htdocs and apache:apache ?
Cheers,
MAL
--
gentoo-dev@gentoo.org mailing list
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] ebuild question
@ 2003-09-19 14:57 Philippe Lafoucrière
2003-09-19 15:03 ` Georgi Georgiev
2003-09-19 15:05 ` Thomas de Grenier de Latour
0 siblings, 2 replies; 56+ messages in thread
From: Philippe Lafoucrière @ 2003-09-19 14:57 UTC (permalink / raw
To: Gentoo-dev
warning : noob question...
I've made an ebuild for the new plastik theme for KDE. When emerging, I
have some warnings like this :
/usr/sbin/ebuild.sh: line 108: /dev/stdout: Permission denied
Any idea ?
here's the ebuild :
# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header:$
inherit kde
need-kde 3.1
DESCRIPTION="Plastik is a widget style and window decoration for KDE
3.x."
HOMEPAGE="http://www.kde-look.org/content/show.php?content=7559"
SRC_URI="http://www.kdelook.org/content/files/7559-${P}.tar.gz"
LICENSE="GPL-2"
SLOT="0"
DEPEND="kde-base/kdebase"
KEYWORDS="x86 ~ppc ~sparc ~alpha"
RESTRICT="nomirror"
pkg_postinst(){
ewarn "HOW TO USE THIS THEME FOR KDE:"
einfo ""
einfo "Open the KDE-Menu and start the Control Center."
einfo "Select \"Look and Feel\"."
einfo "Select \"Style\" if the package you installed was a
style, or"
einfo "select \"Theme Manager\" if the package you installed was
a theme."
einfo "Select your theme or style."
einfo "Click \"Apply\""
einfo ""
einfo "Have fun! :-)"
}
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-09-19 14:57 Philippe Lafoucrière
@ 2003-09-19 15:03 ` Georgi Georgiev
2003-09-19 15:12 ` Philippe Lafoucrière
2003-09-19 15:05 ` Thomas de Grenier de Latour
1 sibling, 1 reply; 56+ messages in thread
From: Georgi Georgiev @ 2003-09-19 15:03 UTC (permalink / raw
To: Gentoo-dev
On 19/09/2003 at 16:57:27(+0200), Philippe Lafoucrière used 1.2K just to say:
> warning : noob question...
>
> I've made an ebuild for the new plastik theme for KDE. When emerging, I
> have some warnings like this :
>
> /usr/sbin/ebuild.sh: line 108: /dev/stdout: Permission denied
>
> Any idea ?
I get this error when I don't have a /dev/stdout file. For example emerging in
a chrooted environment, that doesn't have a /dev mounted. I also get it on a
system where I don't have devfsd installed. Doesn't hurt that much, though.
--
/ Georgi Georgiev / Treaties are like roses and young girls -- /
\ chutz@gg3.net \ they last while they last. -- Charles \
/ +81(90)6266-1163 / DeGaulle /
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-09-19 14:57 Philippe Lafoucrière
2003-09-19 15:03 ` Georgi Georgiev
@ 2003-09-19 15:05 ` Thomas de Grenier de Latour
2003-09-19 15:15 ` Philippe Lafoucrière
1 sibling, 1 reply; 56+ messages in thread
From: Thomas de Grenier de Latour @ 2003-09-19 15:05 UTC (permalink / raw
To: gentoo-dev
En réponse à Philippe Lafoucrière <lafou@wanadoo.fr>:
> /usr/sbin/ebuild.sh: line 108: /dev/stdout: Permission denied
Small portage bug, nothing to worry about.
http://bugs.gentoo.org/show_bug.cgi?id=27306
--
TGL.
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-09-19 15:03 ` Georgi Georgiev
@ 2003-09-19 15:12 ` Philippe Lafoucrière
2003-09-19 15:26 ` Georgi Georgiev
0 siblings, 1 reply; 56+ messages in thread
From: Philippe Lafoucrière @ 2003-09-19 15:12 UTC (permalink / raw
To: Gentoo-dev
> I get this error when I don't have a /dev/stdout file. For example emerging in
> a chrooted environment, that doesn't have a /dev mounted. I also get it on a
> system where I don't have devfsd installed. Doesn't hurt that much, though.
$ ll /dev/stdout
lr-xr-xr-x 1 root root 4 Sep 19 09:17 /dev/stdout ->
fd/1
$ ll /dev/fd/1
lrwx------ 1 root root 64 Sep 19 17:10 /dev/fd/1 ->
/dev/pts/3
ll /dev/pts/3
crw--w---- 1 gravis tty 136, 3 Sep 19 17:10 /dev/pts/3
its own by gravis (my username). It's probably an access problem. Should
I submit a bug report for this ?
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-09-19 15:05 ` Thomas de Grenier de Latour
@ 2003-09-19 15:15 ` Philippe Lafoucrière
0 siblings, 0 replies; 56+ messages in thread
From: Philippe Lafoucrière @ 2003-09-19 15:15 UTC (permalink / raw
To: Thomas de Grenier de Latour; +Cc: Gentoo-dev
> Small portage bug, nothing to worry about.
> http://bugs.gentoo.org/show_bug.cgi?id=27306
k thank you :)
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2003-09-19 15:12 ` Philippe Lafoucrière
@ 2003-09-19 15:26 ` Georgi Georgiev
0 siblings, 0 replies; 56+ messages in thread
From: Georgi Georgiev @ 2003-09-19 15:26 UTC (permalink / raw
To: Gentoo-dev
On 19/09/2003 at 17:12:41(+0200), Philippe Lafoucri鑽e used 0.6K just to say:
>
> > I get this error when I don't have a /dev/stdout file. For example emerging in
> > a chrooted environment, that doesn't have a /dev mounted. I also get it on a
> > system where I don't have devfsd installed. Doesn't hurt that much, though.
>
> $ ll /dev/stdout
> lr-xr-xr-x 1 root root 4 Sep 19 09:17 /dev/stdout ->
> fd/1
>
>
> $ ll /dev/fd/1
> lrwx------ 1 root root 64 Sep 19 17:10 /dev/fd/1 ->
> /dev/pts/3
>
> ll /dev/pts/3
> crw--w---- 1 gravis tty 136, 3 Sep 19 17:10 /dev/pts/3
>
> its own by gravis (my username). It's probably an access problem. Should
> I submit a bug report for this ?
I didn't get the idea of your post.... This cannot be a permissions problem,
because:
$ ll /dev/fd
lr-xr-xr-x 1 root root 13 Sep 17 00:43 /dev/fd -> /proc/self/fd
$ ll /proc/self
lrwxrwxrwx 1 root root 64 Sep 20 00:14 /proc/self -> 18278
You get the idea. The /dev/fd link always points to the file descriptors of the
process looking at that directory. For example
chutz@lion chutz $ ll /dev/fd/
total 0
lrwx------ 1 chutz users 64 Sep 20 00:22 0 -> /dev/pts/1
lrwx------ 1 chutz users 64 Sep 20 00:22 1 -> /dev/pts/1
lrwx------ 1 chutz users 64 Sep 20 00:22 2 -> /dev/pts/1
lr-x------ 1 chutz users 64 Sep 20 00:22 3 -> /proc/18381/fd
chutz@lion chutz $ ll /dev/fd/ 7>&1
total 0
lrwx------ 1 chutz users 64 Sep 20 00:22 0 -> /dev/pts/1
lrwx------ 1 chutz users 64 Sep 20 00:22 1 -> /dev/pts/1
lrwx------ 1 chutz users 64 Sep 20 00:22 2 -> /dev/pts/1
lr-x------ 1 chutz users 64 Sep 20 00:22 3 -> /proc/18382/fd
lrwx------ 1 chutz users 64 Sep 20 00:22 7 -> /dev/pts/1
chutz@lion chutz $ find /dev/fd/
/dev/fd/
/dev/fd/0
/dev/fd/1
/dev/fd/2
/dev/fd/3
/dev/fd/4
chutz@lion chutz $ echo /dev/fd/*
/dev/fd/0 /dev/fd/1 /dev/fd/2 /dev/fd/255 /dev/fd/3
The /dev/fd link is maintained by devfsd.
--
( Georgi Georgiev ( If only one could get that wonderful feeling (
) chutz@gg3.net ) of accomplishment without having to )
( +81(90)6266-1163 ( accomplish anything. (
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* [gentoo-dev] ebuild question
@ 2005-03-03 3:40 pepone pepone
2005-03-03 3:47 ` Jeremy Hanmer
0 siblings, 1 reply; 56+ messages in thread
From: pepone pepone @ 2005-03-03 3:40 UTC (permalink / raw
To: gentoo-dev
Hello I ´m trying to create a new ebuild for Ice (Internet Comunication Engine)
http://www.zeroc.com
this is my first ebuild and i want know how in my ebuild can
detect the version of a program that is installed in the system
the problem is that in order to suscefuly compile my package i need to
export DB_FLAGS and DB_IFLAGS acording to the db version that is instaled
in the system
thanks in adavantage
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2005-03-03 3:40 pepone pepone
@ 2005-03-03 3:47 ` Jeremy Hanmer
2005-03-03 10:26 ` Aaron Walker
0 siblings, 1 reply; 56+ messages in thread
From: Jeremy Hanmer @ 2005-03-03 3:47 UTC (permalink / raw
To: gentoo-dev
you should be able to use the has_version function. More details at
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?
part=2&chap=1
On Mar 2, 2005, at 7:40 PM, pepone pepone wrote:
> Hello I ´m trying to create a new ebuild for Ice (Internet
> Comunication Engine)
> http://www.zeroc.com
>
> this is my first ebuild and i want know how in my ebuild can
> detect the version of a program that is installed in the system
>
> the problem is that in order to suscefuly compile my package i need to
> export DB_FLAGS and DB_IFLAGS acording to the db version that is
> instaled
> in the system
>
> thanks in adavantage
>
> --
> gentoo-dev@gentoo.org mailing list
>
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2005-03-03 3:47 ` Jeremy Hanmer
@ 2005-03-03 10:26 ` Aaron Walker
2005-03-03 20:23 ` Jeremy Hanmer
0 siblings, 1 reply; 56+ messages in thread
From: Aaron Walker @ 2005-03-03 10:26 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeremy Hanmer wrote:
> you should be able to use the has_version function. More details at
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml? part=2&chap=1
has_version only returns 0 or 1 depending whether the package is installed or
not, so it's useless in this case. best_version would be a better alternative,
however that alone won't solve the problem.
Read about best_version in the ebuild(5) manual page. After you're done with
that, read about the versionator eclass in the versionator.eclass(5) manual
page (may have to emerge portage-manpages). You'll probably have to use a
combination of both to do what you're trying to achieve.
HTH
- --
printk(KERN_EMERG "PCI: Tell willy he's wrong
");
linux-2.6.6/arch/parisc/kernel/pci.c
Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCJuZhC3poscuANHARAno+AJ0S4wl1FnzHKuKSeNj92CBKMsOpogCgmhrR
9lSrUePKgaiEePdqlNVZpaM=
=bznu
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2005-03-03 10:26 ` Aaron Walker
@ 2005-03-03 20:23 ` Jeremy Hanmer
2005-03-04 0:42 ` Aaron Walker
0 siblings, 1 reply; 56+ messages in thread
From: Jeremy Hanmer @ 2005-03-03 20:23 UTC (permalink / raw
To: gentoo-dev
On Mar 3, 2005, at 2:26 AM, Aaron Walker wrote:
>
> has_version only returns 0 or 1 depending whether the package is
> installed or
> not, so it's useless in this case. best_version would be a better
> alternative,
> however that alone won't solve the problem.
That's all that's really needed since all you'd care about in this
instance is the existance of one of 2 or 3 major versions. Just look
for >=sys-libs-4.0 then 3.0 and so-on, compiling for the first one you
find.
> Read about best_version in the ebuild(5) manual page. After you're
> done with
> that, read about the versionator eclass in the versionator.eclass(5)
> manual
> page (may have to emerge portage-manpages). You'll probably have to
> use a
> combination of both to do what you're trying to achieve.
>
> HTH
>
> - --
> printk(KERN_EMERG "PCI: Tell willy he's wrong
> ");
> linux-2.6.6/arch/parisc/kernel/pci.c
>
> Aaron Walker <ka0ttic@gentoo.org>
> [ BSD | cron | forensics | shell-tools | commonbox | netmon | vim |
> web-apps ]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (GNU/Linux)
>
> iD8DBQFCJuZhC3poscuANHARAno+AJ0S4wl1FnzHKuKSeNj92CBKMsOpogCgmhrR
> 9lSrUePKgaiEePdqlNVZpaM=
> =bznu
> -----END PGP SIGNATURE-----
> --
> gentoo-dev@gentoo.org mailing list
>
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [gentoo-dev] ebuild question
2005-03-03 20:23 ` Jeremy Hanmer
@ 2005-03-04 0:42 ` Aaron Walker
0 siblings, 0 replies; 56+ messages in thread
From: Aaron Walker @ 2005-03-04 0:42 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeremy Hanmer wrote:
>
> On Mar 3, 2005, at 2:26 AM, Aaron Walker wrote:
>
>>
>> has_version only returns 0 or 1 depending whether the package is
>> installed or
>> not, so it's useless in this case. best_version would be a better
>> alternative,
>> however that alone won't solve the problem.
>
>
> That's all that's really needed since all you'd care about in this
> instance is the existance of one of 2 or 3 major versions. Just look
> for >=sys-libs-4.0 then 3.0 and so-on, compiling for the first one you
> find.
That would be the incorrect way of going about it. As I said in my previous
post, use versionator.eclass. One call to best_version and one call to
get_major_version is all that's needed.
- --
Love America -- or give it back.
Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCJ678C3poscuANHARAn1hAKDGWTixj9QVHjCMLgzLu75yLmywbgCfT1+h
YlWOglosHIp5XrbfHE/u4XA=
=VZ1q
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2005-03-04 0:42 UTC | newest]
Thread overview: 56+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-06-10 14:25 [gentoo-dev] ebuild question MAL
2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
2003-06-10 16:07 ` Matthew Kennedy
2003-06-10 18:05 ` John Robinson
2003-06-10 20:20 ` Philippe Lafoucrière
2003-06-11 3:18 ` Luke Graham
2003-06-11 5:10 ` Bill Kenworthy
2003-06-10 21:56 ` MooktaKiNG
2003-06-10 21:42 ` Zach Forrest
2003-06-10 23:26 ` Kumba
2003-06-11 11:52 ` [gentoo-dev] Readme files for portage (was: A nice idea to improve portage) Svyatogor
2003-06-11 10:37 ` MooktaKiNG
2003-06-11 10:10 ` Michael Cummings
2003-06-11 10:44 ` Paul de Vrieze
2003-06-11 13:24 ` [gentoo-dev] " D. Tuinstra
2003-06-11 15:47 ` oford
2003-06-11 17:06 ` [gentoo-dev] " MooktaKiNG
2003-06-12 11:34 ` [gentoo-dev] ebuild question Amiel Martin
-- strict thread matches above, loose matches on Subject: below --
2005-03-03 3:40 pepone pepone
2005-03-03 3:47 ` Jeremy Hanmer
2005-03-03 10:26 ` Aaron Walker
2005-03-03 20:23 ` Jeremy Hanmer
2005-03-04 0:42 ` Aaron Walker
2003-09-19 14:57 Philippe Lafoucrière
2003-09-19 15:03 ` Georgi Georgiev
2003-09-19 15:12 ` Philippe Lafoucrière
2003-09-19 15:26 ` Georgi Georgiev
2003-09-19 15:05 ` Thomas de Grenier de Latour
2003-09-19 15:15 ` Philippe Lafoucrière
2003-05-30 15:17 William Hubbs
2003-05-30 15:27 ` Grant Goodyear
2003-05-31 3:00 ` Georgi Georgiev
2003-05-30 11:15 MAL
2003-05-30 11:29 ` Alastair Tse
2003-05-30 14:22 ` MAL
2003-05-30 14:33 ` Alastair Tse
2003-05-30 14:40 ` Todd Berman
2003-05-30 14:55 ` Jon Portnoy
2003-05-30 15:08 ` MAL
2003-05-30 14:39 ` Seemant Kulleen
2003-05-30 15:09 ` Seemant Kulleen
2002-11-26 21:27 Per Wigren
2002-11-26 21:23 ` Dan Armak
2002-11-27 0:03 ` Per Wigren
2002-07-26 14:54 John Matthews
2002-04-18 6:13 Avi Schwartz
2002-04-18 6:59 ` George Shapovalov
2002-04-18 7:15 ` Tod M Neidt
2002-04-17 5:21 Richard Jackson
2002-04-17 5:02 ` Jared H. Hudson
2002-04-17 6:05 ` Richard Jackson
2002-04-17 5:21 ` Jared H. Hudson
2002-02-07 3:44 Edward Muller
2002-02-07 4:43 ` Tod M Neidt
2001-08-05 15:50 Craig Joly
2001-08-05 17:07 ` Daniel Robbins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox