[gentoo-dev] ebuild question

[gentoo-dev] ebuild question

[MAL]

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] A nice idea to improve portage

[MooktaKiNG]

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

Re: [gentoo-dev] A nice idea to improve portage

[Matthew Kennedy]

"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

Re: [gentoo-dev] A nice idea to improve portage

[John Robinson]

> 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

Re: [gentoo-dev] A nice idea to improve portage

[Philippe Lafoucrière]

> 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

Re: [gentoo-dev] A nice idea to improve portage

[Luke Graham]

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

Re: [gentoo-dev] A nice idea to improve portage

[Bill Kenworthy]

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

Re: [gentoo-dev] A nice idea to improve portage

[MooktaKiNG]

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

Re: [gentoo-dev] A nice idea to improve portage

[Zach Forrest]

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

Re: [gentoo-dev] A nice idea to improve portage

[Kumba]

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

[gentoo-dev] Readme files for portage (was: A nice idea to improve portage)

[Svyatogor]

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

Re: [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)

[MooktaKiNG]

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

Re: [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)

[Michael Cummings]

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

Re: [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)

[Paul de Vrieze]

[-- 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 --]

[gentoo-dev] Re: Readme files for portage (was: A nice idea to improve portage)

[D. Tuinstra]

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

Re: [gentoo-dev] Re: Readme files for portage (was: A nice idea to improve portage)

[oford]

[-- 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 --]

Re: [gentoo-dev] Readme files for portage (was: A nice idea to improve portage)

[MooktaKiNG]

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

Re: [gentoo-dev] ebuild question

[Amiel Martin]

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