Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
Date: Sun, 23 Dec 2012 09:57:50
Message-Id: 1356256625.3434.15.camel@belkin4
In Reply to: Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information by Zac Medico
1 El sáb, 22-12-2012 a las 13:53 -0800, Zac Medico escribió:
2 > On 12/22/2012 01:46 PM, Markos Chandras wrote:
3 > > On 22 December 2012 09:26, Pacho Ramos <pacho@g.o> wrote:
4 > >> Hello
5 > >>
6 > >> After seeing:
7 > >> https://bugs.gentoo.org/show_bug.cgi?id=440214
8 > >>
9 > >> Looking to a lot of its blockers shows that we are using "elog" messages
10 > >> for informing people about configuration (like pointing people to
11 > >> external links to get proper way of configuring things, tell them to add
12 > >> to some system groups...). I thought that maybe this kind of information
13 > >> could be simply included in a canonical file under /usr/share/doc/
14 > >> package dir called, for example, CONFIGURATION or SETUP. We would them
15 > >> point people (now with a news item, for the long term provably a note to
16 > >> handbook to newcomers would be nice) to that file to configure their
17 > >> setups. The main advantages I see:
18 > >> - We will flood less summary.log ;)
19 > >> - The information to configure the package is always present while
20 > >> package is installed, now, if we remove merge produced logs, people will
21 > >> need to reemerge the package or read directly the ebuild
22 > >>
23 > >> What do you think?
24 > >
25 > > Correct me if I am wrong but are you suggesting we drop the elog
26 > > messages altogether? I still believe that having the elog messages
27 > > at the end of an 'emerge -uDN world' is more convenient. Maybe it
28 > > makes sense to have both, as in print the elog messages and
29 > > create those CONFIGURATION or SETUP files at the same time.
30 >
31 > As a compromise, you could have the ebuild trigger the elog message only
32 > when there is not a previous version of the package installed.
33
34 That sounds interesting in combination :O Looking to, for example, e4rat
35 ebuild, it should elog the info to configure it first time and later
36 people could rely on CONFIGURATION doc to recover that information, not
37 flooding summary.log any longer and not losing the info, looks nice :D

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies