[gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

Hello

After seeing:
https://bugs.gentoo.org/show_bug.cgi?id=440214

Looking to a lot of its blockers shows that we are using "elog" messages
for informing people about configuration (like pointing people to
external links to get proper way of configuring things, tell them to add
to some system groups...). I thought that maybe this kind of information
could be simply included in a canonical file under /usr/share/doc/
package dir called, for example, CONFIGURATION or SETUP. We would them
point people (now with a news item, for the long term provably a note to
handbook to newcomers would be nice) to that file to configure their
setups. The main advantages I see:
- We will flood less summary.log ;)
- The information to configure the package is always present while
package is installed, now, if we remove merge produced logs, people will
need to reemerge the package or read directly the ebuild

What do you think?

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Amadeusz Żołnowski]

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

Quoting Pacho Ramos (2012-12-22 10:26:40)
> I thought that maybe this kind of information could be simply included
> in a canonical file under /usr/share/doc/ package dir called, for
> example, CONFIGURATION or SETUP.
>
> What do you think?

At last! +100

-- 
Amadeusz Żołnowski

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAABAgAGBQJQ1cxVAAoJEPATRTHh2/q1D/sH/235gUtjQQPaOyzO4jWfY4xK
bBXKdmiu4QNpew/bJhWzHL5fs0dFem9/5GHjlcHkE5+RdBIffHucDpia7KVxc6Y/
TJNtxKn4AbVkG+cNKDIYhQXSjGJGciAPayiRKw2jhyfWFOIzkik3RwyuA7OxUAex
jPC/bwM0K0xkLeBX1+Z7aXa/XvyeWs1w0fImueKD5z1ckSNS3uaGek8YXkNROcU3
ShTTxi1t/wcCjR+VeTvYFKpoeB0slLFWaY0pn8tG1IZJDT/EIU4LtU7EOxw1iw6y
p4T6osR1hjfVsJL7eyZmYJtYOEJrGjWOE7hofpTDu+B34rwV9H8Zpn2NVAmLDwU=
=wg/J
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Brian Dolbec]

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

On Sat, 2012-12-22 at 10:26 +0100, Pacho Ramos wrote:
> Hello
> 
> After seeing:
> https://bugs.gentoo.org/show_bug.cgi?id=440214
> 
> Looking to a lot of its blockers shows that we are using "elog" messages
> for informing people about configuration (like pointing people to
> external links to get proper way of configuring things, tell them to add
> to some system groups...). I thought that maybe this kind of information
> could be simply included in a canonical file under /usr/share/doc/
> package dir called, for example, CONFIGURATION or SETUP. We would them
> point people (now with a news item, for the long term provably a note to
> handbook to newcomers would be nice) to that file to configure their
> setups. The main advantages I see:
> - We will flood less summary.log ;)
> - The information to configure the package is always present while
> package is installed, now, if we remove merge produced logs, people will
> need to reemerge the package or read directly the ebuild
> 
> What do you think?

I think that sounds like a perfectly acceptable solution for many of
those.


For layman, I ended up moving those elog messages to a layman-updater
script (needed for something else) which was capable of knowing what
messages were relevant to display.  I run that layman-updater script in 
pkg_postinst().
-- 
Brian Dolbec <dolsen@gentoo.org>

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Markos Chandras]

On 22 December 2012 09:26, Pacho Ramos <pacho@gentoo.org> wrote:
> Hello
>
> After seeing:
> https://bugs.gentoo.org/show_bug.cgi?id=440214
>
> Looking to a lot of its blockers shows that we are using "elog" messages
> for informing people about configuration (like pointing people to
> external links to get proper way of configuring things, tell them to add
> to some system groups...). I thought that maybe this kind of information
> could be simply included in a canonical file under /usr/share/doc/
> package dir called, for example, CONFIGURATION or SETUP. We would them
> point people (now with a news item, for the long term provably a note to
> handbook to newcomers would be nice) to that file to configure their
> setups. The main advantages I see:
> - We will flood less summary.log ;)
> - The information to configure the package is always present while
> package is installed, now, if we remove merge produced logs, people will
> need to reemerge the package or read directly the ebuild
>
> What do you think?

Correct me if I am wrong but are you suggesting we drop the elog
messages altogether? I still believe that having the elog messages
at the end of an 'emerge -uDN world' is more convenient. Maybe it
makes sense to have both, as in print the elog messages and
create those CONFIGURATION or SETUP files at the same time.

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 12/22/2012 01:46 PM, Markos Chandras wrote:
> On 22 December 2012 09:26, Pacho Ramos <pacho@gentoo.org> wrote:
>> Hello
>>
>> After seeing:
>> https://bugs.gentoo.org/show_bug.cgi?id=440214
>>
>> Looking to a lot of its blockers shows that we are using "elog" messages
>> for informing people about configuration (like pointing people to
>> external links to get proper way of configuring things, tell them to add
>> to some system groups...). I thought that maybe this kind of information
>> could be simply included in a canonical file under /usr/share/doc/
>> package dir called, for example, CONFIGURATION or SETUP. We would them
>> point people (now with a news item, for the long term provably a note to
>> handbook to newcomers would be nice) to that file to configure their
>> setups. The main advantages I see:
>> - We will flood less summary.log ;)
>> - The information to configure the package is always present while
>> package is installed, now, if we remove merge produced logs, people will
>> need to reemerge the package or read directly the ebuild
>>
>> What do you think?
> 
> Correct me if I am wrong but are you suggesting we drop the elog
> messages altogether? I still believe that having the elog messages
> at the end of an 'emerge -uDN world' is more convenient. Maybe it
> makes sense to have both, as in print the elog messages and
> create those CONFIGURATION or SETUP files at the same time.

As a compromise, you could have the ebuild trigger the elog message only
when there is not a previous version of the package installed.
-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Markos Chandras]

On 22 December 2012 21:53, Zac Medico <zmedico@gentoo.org> wrote:
> On 12/22/2012 01:46 PM, Markos Chandras wrote:
>> On 22 December 2012 09:26, Pacho Ramos <pacho@gentoo.org> wrote:
>>> Hello
>>>
>>> After seeing:
>>> https://bugs.gentoo.org/show_bug.cgi?id=440214
>>>
>>> Looking to a lot of its blockers shows that we are using "elog" messages
>>> for informing people about configuration (like pointing people to
>>> external links to get proper way of configuring things, tell them to add
>>> to some system groups...). I thought that maybe this kind of information
>>> could be simply included in a canonical file under /usr/share/doc/
>>> package dir called, for example, CONFIGURATION or SETUP. We would them
>>> point people (now with a news item, for the long term provably a note to
>>> handbook to newcomers would be nice) to that file to configure their
>>> setups. The main advantages I see:
>>> - We will flood less summary.log ;)
>>> - The information to configure the package is always present while
>>> package is installed, now, if we remove merge produced logs, people will
>>> need to reemerge the package or read directly the ebuild
>>>
>>> What do you think?
>>
>> Correct me if I am wrong but are you suggesting we drop the elog
>> messages altogether? I still believe that having the elog messages
>> at the end of an 'emerge -uDN world' is more convenient. Maybe it
>> makes sense to have both, as in print the elog messages and
>> create those CONFIGURATION or SETUP files at the same time.
>
> As a compromise, you could have the ebuild trigger the elog message only
> when there is not a previous version of the package installed.
> --
> Thanks,
> Zac
>

Well yeah, plus the elog messages are logged in /var/log/portage/elog
so duplicating them in /usr/share/doc/$PF/SETUP does not make much
sense to me :/

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El sáb, 22-12-2012 a las 21:46 +0000, Markos Chandras escribió:
> On 22 December 2012 09:26, Pacho Ramos <pacho@gentoo.org> wrote:
> > Hello
> >
> > After seeing:
> > https://bugs.gentoo.org/show_bug.cgi?id=440214
> >
> > Looking to a lot of its blockers shows that we are using "elog" messages
> > for informing people about configuration (like pointing people to
> > external links to get proper way of configuring things, tell them to add
> > to some system groups...). I thought that maybe this kind of information
> > could be simply included in a canonical file under /usr/share/doc/
> > package dir called, for example, CONFIGURATION or SETUP. We would them
> > point people (now with a news item, for the long term provably a note to
> > handbook to newcomers would be nice) to that file to configure their
> > setups. The main advantages I see:
> > - We will flood less summary.log ;)
> > - The information to configure the package is always present while
> > package is installed, now, if we remove merge produced logs, people will
> > need to reemerge the package or read directly the ebuild
> >
> > What do you think?
> 
> Correct me if I am wrong but are you suggesting we drop the elog
> messages altogether? 

No, only to drop its usage for configuration stuff (like that kind of
message telling you to go to page XXXX to know how to configure your
app)


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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El sáb, 22-12-2012 a las 13:53 -0800, Zac Medico escribió:
> On 12/22/2012 01:46 PM, Markos Chandras wrote:
> > On 22 December 2012 09:26, Pacho Ramos <pacho@gentoo.org> wrote:
> >> Hello
> >>
> >> After seeing:
> >> https://bugs.gentoo.org/show_bug.cgi?id=440214
> >>
> >> Looking to a lot of its blockers shows that we are using "elog" messages
> >> for informing people about configuration (like pointing people to
> >> external links to get proper way of configuring things, tell them to add
> >> to some system groups...). I thought that maybe this kind of information
> >> could be simply included in a canonical file under /usr/share/doc/
> >> package dir called, for example, CONFIGURATION or SETUP. We would them
> >> point people (now with a news item, for the long term provably a note to
> >> handbook to newcomers would be nice) to that file to configure their
> >> setups. The main advantages I see:
> >> - We will flood less summary.log ;)
> >> - The information to configure the package is always present while
> >> package is installed, now, if we remove merge produced logs, people will
> >> need to reemerge the package or read directly the ebuild
> >>
> >> What do you think?
> > 
> > Correct me if I am wrong but are you suggesting we drop the elog
> > messages altogether? I still believe that having the elog messages
> > at the end of an 'emerge -uDN world' is more convenient. Maybe it
> > makes sense to have both, as in print the elog messages and
> > create those CONFIGURATION or SETUP files at the same time.
> 
> As a compromise, you could have the ebuild trigger the elog message only
> when there is not a previous version of the package installed.

That sounds interesting in combination :O Looking to, for example, e4rat
ebuild, it should elog the info to configure it first time and later
people could rely on CONFIGURATION doc to recover that information, not
flooding summary.log any longer and not losing the info, looks nice :D

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Markos Chandras]

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

But like I said, elog messages are already saved in
/var/log/portage/elog/$cat/$pf so people can
read these. Isn't this the same with what you suggest?

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Alexandre Rostovtsev]

On Sun, 2012-12-23 at 12:20 +0000, Markos Chandras wrote:
> But like I said, elog messages are already saved in
> /var/log/portage/elog/$cat/$pf so people can
> read these. Isn't this the same with what you suggest?

Is that by default? And when was that default added? 

I certainly do not have /var/log/portage/elog/$cat/$pf on my machine
(using portage-2.2.0_alpha149), and in fact have never heard of this log
file before your email.

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Markos Chandras]

On 23 December 2012 13:58, Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> On Sun, 2012-12-23 at 12:20 +0000, Markos Chandras wrote:
>> But like I said, elog messages are already saved in
>> /var/log/portage/elog/$cat/$pf so people can
>> read these. Isn't this the same with what you suggest?
>
> Is that by default? And when was that default added?
>
> I certainly do not have /var/log/portage/elog/$cat/$pf on my machine
> (using portage-2.2.0_alpha149), and in fact have never heard of this log
> file before your email.
>
>

Good question. I believe this is handled by the PORTAGE_ELOG_*
variables in /etc/portage/make.conf

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Brian Dolbec]

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

On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote:
> On Sun, 2012-12-23 at 12:20 +0000, Markos Chandras wrote:
> > But like I said, elog messages are already saved in
> > /var/log/portage/elog/$cat/$pf so people can
> > read these. Isn't this the same with what you suggest?
> 
> Is that by default? And when was that default added? 
> 
> I certainly do not have /var/log/portage/elog/$cat/$pf on my machine
> (using portage-2.2.0_alpha149), and in fact have never heard of this log
> file before your email.
> 
> 

No, they are not saved there by default.  They must be enabled.

elog messages are not saved there, those are the build logs. They are
saved in /var/log/portage/elog/  as for example:

app-portage:gentoolkit-0.3.0.7:20121216-000453.log

PLUS, they can be cleaned by emaint or setup to be auto-cleaned by
emerge as well so as to not fill up the system with old build logs.

emaint -p logs

the default is 7 days old, will be cleaned.  The emaint log module also
takes a -t, --time option.


Pacho was right with his original email.  It would be best to install
that small text file of info where it can be found for reference later.
I have often had to go searching ebuilds for elog/einfo data about
configuring some pkg for such and such long after it's first install due
to needs changing or some breakage of some kind.

Much like our gentoo handbook, where most of that info can be found
elswhere on the net, this would extend to pkgs so that that info could
be compiled together in a place that did not require net access to find
key info needed.

This proposed method would not apply to all those pkgs with over use of
elog/einfo either.  Many of those just need to use has_version() to
reduce the noise.  But there are many such pkgs in the tree that could
benefit from the dev putting together a small doc of the configuration
info for gentoo, put it into the files dir to be installed as Pacho
suggests.  It would likely reduce the number of bugs submitted due to
bad configuration and make it easier for users to locate (after some
time to get use to the idea where to find them).
-- 
Brian Dolbec <dolsen@gentoo.org>

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 12/23/2012 08:35 AM, Brian Dolbec wrote:
> On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote:
>> On Sun, 2012-12-23 at 12:20 +0000, Markos Chandras wrote:
>>> But like I said, elog messages are already saved in
>>> /var/log/portage/elog/$cat/$pf so people can
>>> read these. Isn't this the same with what you suggest?
>>
>> Is that by default? And when was that default added? 
>>
>> I certainly do not have /var/log/portage/elog/$cat/$pf on my machine
>> (using portage-2.2.0_alpha149), and in fact have never heard of this log
>> file before your email.
>>
>>
> 
> No, they are not saved there by default.  They must be enabled.

/var/log/portage/elog/summary.log is enabled by default though, and
portage installs /etc/logrotate.d/elog-save-summary to manage it.
-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El dom, 23-12-2012 a las 13:36 -0800, Zac Medico escribió:
> On 12/23/2012 08:35 AM, Brian Dolbec wrote:
> > On Sun, 2012-12-23 at 08:58 -0500, Alexandre Rostovtsev wrote:
> >> On Sun, 2012-12-23 at 12:20 +0000, Markos Chandras wrote:
> >>> But like I said, elog messages are already saved in
> >>> /var/log/portage/elog/$cat/$pf so people can
> >>> read these. Isn't this the same with what you suggest?
> >>
> >> Is that by default? And when was that default added? 
> >>
> >> I certainly do not have /var/log/portage/elog/$cat/$pf on my machine
> >> (using portage-2.2.0_alpha149), and in fact have never heard of this log
> >> file before your email.
> >>
> >>
> > 
> > No, they are not saved there by default.  They must be enabled.
> 
> /var/log/portage/elog/summary.log is enabled by default though, and
> portage installs /etc/logrotate.d/elog-save-summary to manage it.

But I remember to, for example, this kind of message:
        elog
        elog "Please consult the upstream wiki if you need help"
        elog "configuring your system"
        elog "http://e4rat.sourceforge.net/wiki/index.php/Main_Page"
        elog


The idea would be to make it to be only shown at first message and,
later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION
file if they want to remember that tip


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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Diego Elio Pettenò]

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

On 23/12/2012 23:54, Pacho Ramos wrote:
> The idea would be to make it to be only shown at first message and,
> later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION
> file if they want to remember that tip

So you want in the main documentation a request to read the package
documentation on where to find the upstream documentation?

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El lun, 24-12-2012 a las 00:17 +0100, Diego Elio Pettenò escribió:
> On 23/12/2012 23:54, Pacho Ramos wrote:
> > The idea would be to make it to be only shown at first message and,
> > later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION
> > file if they want to remember that tip
> 
> So you want in the main documentation a request to read the package
> documentation on where to find the upstream documentation?
> 

I want to have a permanent reference of current elog messages simply
showing configuration tips to:
1. Show them via elog messages only first time package is installed
2. Not need to read ebuild directly once people remove summary.log


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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El lun, 24-12-2012 a las 00:30 +0100, Pacho Ramos escribió:
> El lun, 24-12-2012 a las 00:17 +0100, Diego Elio Pettenò escribió:
> > On 23/12/2012 23:54, Pacho Ramos wrote:
> > > The idea would be to make it to be only shown at first message and,
> > > later, rely on people reading /usr/share/doc/e4rat-xxx/CONFIGURATION
> > > file if they want to remember that tip
> > 
> > So you want in the main documentation a request to read the package
> > documentation on where to find the upstream documentation?
> > 
> 
> I want to have a permanent reference of current elog messages simply
> showing configuration tips to:
> 1. Show them via elog messages only first time package is installed
> 2. Not need to read ebuild directly once people remove summary.log
> 

More examples I saw today when updating:
- lm_sensors -> shows configuration tips every time it's merged, the
idea would be to show it via elog only at first merge and, later, rely
on /usr/share/doc file
- nvidia-drivers -> things like telling people to add them to video
group could be treated in the same way, the same probably for eselect
instructions.



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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/12/12 00:09, Pacho Ramos wrote:
> More examples I saw today when updating: - nvidia-drivers -> things
> like telling people to add them to video group could be treated in
> the same way, the same probably for eselect instructions.
Every game reminds you that you need to be in the games group to play
them every time you emerge them. Quite annoying behaviour.


- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlDfeswACgkQRtClrXBQc7WiZwD9G74WZH58pSyL7Hs2o7Dt6K4Z
bMAPA0cGD1/7f6qJviAA/2ErR4bWW/Ma3Zyhkr56YnnbWpgHg84UOPAxwH5oO/yO
=4d6G
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El dom, 30-12-2012 a las 00:09 +0100, Pacho Ramos escribió:
[...]
> > I want to have a permanent reference of current elog messages simply
> > showing configuration tips to:
> > 1. Show them via elog messages only first time package is installed
> > 2. Not need to read ebuild directly once people remove summary.log
> > 

This would be the idea (applied in this example to acpid package)
--- /home/pacho/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild
2012-11-26 09:20:15.000000000 +0100
+++ ./acpid-2.0.17.ebuild	2012-12-31 14:18:41.000000000 +0100
@@ -37,6 +37,13 @@
 	newconfd "${FILESDIR}"/${PN}-2.0.16-conf.d ${PN}
 
 	systemd_dounit "${FILESDIR}"/systemd/${PN}.{service,socket}
+
+	cat > CONFIGURATION <<-EOF
+		You may wish to read the Gentoo Linux Power Management Guide,
+		which can be found online at:
+		http://www.gentoo.org/doc/en/power-management-guide.xml
+	EOF
+	dodoc CONFIGURATION
 }
 
 pkg_postinst() {

Some improvements I am not sure how to implement just now:
- What would be the proper way to "elog" contents
of /usr/share/doc/${PF}/CONFIGURATION.bz2 and, then, allow the following
to be shorter:

	if ! has_version 'sys-power/acpid'; then
		elog
		elog "You may wish to read the Gentoo Linux Power Management Guide,"
		elog "which can be found online at:"
		elog "http://www.gentoo.org/doc/en/power-management-guide.xml"
		elog
	fi
?

Thanks for your help

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 12/31/2012 05:21 AM, Pacho Ramos wrote:
>  pkg_postinst() {
> 
> Some improvements I am not sure how to implement just now:
> - What would be the proper way to "elog" contents
> of /usr/share/doc/${PF}/CONFIGURATION.bz2 and, then, allow the following
> to be shorter:
> 
> 	if ! has_version 'sys-power/acpid'; then
> 		elog
> 		elog "You may wish to read the Gentoo Linux Power Management Guide,"
> 		elog "which can be found online at:"
> 		elog "http://www.gentoo.org/doc/en/power-management-guide.xml"
> 		elog
> 	fi
> ?
> 
> Thanks for your help
> 

It seems that you're allowed to call the unpack() function in any phase,
so something like this should work:

  cd "${T}"
  cp "${EROOT}/usr/share/doc/${PF}/CONFIGURATION"* ./
  [ -f ./CONFIGURATION ] || unpack ./CONFIGURATION*
  elog "$(< ./CONFIGURATION)"


-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El lun, 31-12-2012 a las 14:53 -0800, Zac Medico escribió:
> On 12/31/2012 05:21 AM, Pacho Ramos wrote:
> >  pkg_postinst() {
> > 
> > Some improvements I am not sure how to implement just now:
> > - What would be the proper way to "elog" contents
> > of /usr/share/doc/${PF}/CONFIGURATION.bz2 and, then, allow the following
> > to be shorter:
> > 
> > 	if ! has_version 'sys-power/acpid'; then
> > 		elog
> > 		elog "You may wish to read the Gentoo Linux Power Management Guide,"
> > 		elog "which can be found online at:"
> > 		elog "http://www.gentoo.org/doc/en/power-management-guide.xml"
> > 		elog
> > 	fi
> > ?
> > 
> > Thanks for your help
> > 
> 
> It seems that you're allowed to call the unpack() function in any phase,
> so something like this should work:
> 
>   cd "${T}"
>   cp "${EROOT}/usr/share/doc/${PF}/CONFIGURATION"* ./
>   [ -f ./CONFIGURATION ] || unpack ./CONFIGURATION*
>   elog "$(< ./CONFIGURATION)"
> 
> 

Thanks a lot for the tip :)

On the other hand, I have seen another way of doing that looking at
kernel-2.eclass:
--- /home/pacho/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild
2012-11-26 09:20:15.000000000 +0100
+++ ./acpid-2.0.17.ebuild	2013-01-01 14:30:18.000000000 +0100
@@ -17,6 +17,11 @@
 RDEPEND="selinux? ( sec-policy/selinux-apm )"
 DEPEND="${RDEPEND}"
 
+CONFIGURATION_INSTRUCTIONS="
+	You may wish to read the Gentoo Linux Power Management Guide,
+	which can be found online at:
+	http://www.gentoo.org/doc/en/power-management-guide.xml"
+
 src_configure() {
 	econf --docdir=/usr/share/doc/${PF}
 }
@@ -37,6 +42,9 @@
 	newconfd "${FILESDIR}"/${PN}-2.0.16-conf.d ${PN}
 
 	systemd_dounit "${FILESDIR}"/systemd/${PN}.{service,socket}
+
+	echo ${CONFIGURATION_INSTRUCTIONS} | fmt > CONFIGURATION
+	dodoc CONFIGURATION
 }
 
 pkg_postinst() {
@@ -48,6 +56,8 @@
 		elog
 	fi
 
+	echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
elog "${ELINE}"; done
+
 	# files/systemd/acpid.socket -> ListenStream=/run/acpid.socket
 	mkdir -p "${ROOT}"/run

This could probably be moved to eutils.eclass to use it on this kind of
ebuilds

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
[...]
> --- /home/pacho/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild
> 2012-11-26 09:20:15.000000000 +0100
> +++ ./acpid-2.0.17.ebuild	2013-01-01 14:30:18.000000000 +0100
> @@ -17,6 +17,11 @@
>  RDEPEND="selinux? ( sec-policy/selinux-apm )"
>  DEPEND="${RDEPEND}"
>  
> +CONFIGURATION_INSTRUCTIONS="
> +	You may wish to read the Gentoo Linux Power Management Guide,
> +	which can be found online at:
> +	http://www.gentoo.org/doc/en/power-management-guide.xml"
> +
>  src_configure() {
>  	econf --docdir=/usr/share/doc/${PF}
>  }
> @@ -37,6 +42,9 @@
>  	newconfd "${FILESDIR}"/${PN}-2.0.16-conf.d ${PN}
>  
>  	systemd_dounit "${FILESDIR}"/systemd/${PN}.{service,socket}
> +
> +	echo ${CONFIGURATION_INSTRUCTIONS} | fmt > CONFIGURATION
> +	dodoc CONFIGURATION
>  }
>  
>  pkg_postinst() {
> @@ -48,6 +56,8 @@
>  		elog
>  	fi
>  
> +	echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
> elog "${ELINE}"; done
> +
>  	# files/systemd/acpid.socket -> ListenStream=/run/acpid.socket
>  	mkdir -p "${ROOT}"/run
> 
> This could probably be moved to eutils.eclass to use it on this kind of
> ebuilds

Well, "elog" part should be behind:
if ! has_version "${CATEGORY}/${PN}"; then
	echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
"${ELINE}"; done
fi


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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/01/2013 05:39 AM, Pacho Ramos wrote:
> El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
>>  pkg_postinst() {
>> @@ -48,6 +56,8 @@
>>  		elog
>>  	fi
>>  
>> +	echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
>> elog "${ELINE}"; done
>> +
>>  	# files/systemd/acpid.socket -> ListenStream=/run/acpid.socket
>>  	mkdir -p "${ROOT}"/run
>>
>> This could probably be moved to eutils.eclass to use it on this kind of
>> ebuilds
> 
> Well, "elog" part should be behind:
> if ! has_version "${CATEGORY}/${PN}"; then
> 	echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
> "${ELINE}"; done
> fi
> 

Not that `has_version "${CATEGORY}/${PN}"` is always true in
pkg_postinst, since the package is already installed. So, you should
choose one of these alternatives for it to work as intended:

1) call has_version in pkg_preinst
2) use [[ ${REPLACING_VERSIONS} ]] instead

-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El mar, 01-01-2013 a las 16:01 -0800, Zac Medico escribió:
> On 01/01/2013 05:39 AM, Pacho Ramos wrote:
> > El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
> >>  pkg_postinst() {
> >> @@ -48,6 +56,8 @@
> >>  		elog
> >>  	fi
> >>  
> >> +	echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
> >> elog "${ELINE}"; done
> >> +
> >>  	# files/systemd/acpid.socket -> ListenStream=/run/acpid.socket
> >>  	mkdir -p "${ROOT}"/run
> >>
> >> This could probably be moved to eutils.eclass to use it on this kind of
> >> ebuilds
> > 
> > Well, "elog" part should be behind:
> > if ! has_version "${CATEGORY}/${PN}"; then
> > 	echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
> > "${ELINE}"; done
> > fi
> > 
> 
> Not that `has_version "${CATEGORY}/${PN}"` is always true in
> pkg_postinst, since the package is already installed. So, you should
> choose one of these alternatives for it to work as intended:
> 
> 1) call has_version in pkg_preinst
> 2) use [[ ${REPLACING_VERSIONS} ]] instead
> 

Yeah, that is true (and looks like current acpid ebuild is buggy in
this). I wouldn't have any problem on either solution, but using first
one would work in all eapis, is there any reason for printing this kind
of messages in pkg_postinst?

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/02/2013 03:48 AM, Pacho Ramos wrote:
> El mar, 01-01-2013 a las 16:01 -0800, Zac Medico escribió:
>> On 01/01/2013 05:39 AM, Pacho Ramos wrote:
>>> El mar, 01-01-2013 a las 14:32 +0100, Pacho Ramos escribió:
>>>>  pkg_postinst() {
>>>> @@ -48,6 +56,8 @@
>>>>  		elog
>>>>  	fi
>>>>  
>>>> +	echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do
>>>> elog "${ELINE}"; done
>>>> +
>>>>  	# files/systemd/acpid.socket -> ListenStream=/run/acpid.socket
>>>>  	mkdir -p "${ROOT}"/run
>>>>
>>>> This could probably be moved to eutils.eclass to use it on this kind of
>>>> ebuilds
>>>
>>> Well, "elog" part should be behind:
>>> if ! has_version "${CATEGORY}/${PN}"; then
>>> 	echo ${CONFIGURATION_INSTRUCTIONS} | fmt | while read -s ELINE; do elog
>>> "${ELINE}"; done
>>> fi
>>>
>>
>> Not that `has_version "${CATEGORY}/${PN}"` is always true in
>> pkg_postinst, since the package is already installed. So, you should
>> choose one of these alternatives for it to work as intended:
>>
>> 1) call has_version in pkg_preinst
>> 2) use [[ ${REPLACING_VERSIONS} ]] instead
>>
> 
> Yeah, that is true (and looks like current acpid ebuild is buggy in
> this). I wouldn't have any problem on either solution, but using first
> one would work in all eapis, is there any reason for printing this kind
> of messages in pkg_postinst?

If you need to use pkg_postinst for any reason, you can still call
has_version in pkg_preinst and use a variable to store the result, like
this:

	pkg_preinst() {
		has_version "${CATEGORY}/${PN}"
		has_version_result=$?
	}

	pkg_postinst() {
		if [ ${has_version_result} -eq 0 ] ; then
			elog "${CONFIGURATION_INSTRUCTIONS}"
		fi
	}
-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Donnie Berkholz]

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

On 10:26 Sat 22 Dec     , Pacho Ramos wrote:
> Hello
> 
> After seeing:
> https://bugs.gentoo.org/show_bug.cgi?id=440214
> 
> Looking to a lot of its blockers shows that we are using "elog" messages
> for informing people about configuration (like pointing people to
> external links to get proper way of configuring things, tell them to add
> to some system groups...). I thought that maybe this kind of information
> could be simply included in a canonical file under /usr/share/doc/
> package dir called, for example, CONFIGURATION or SETUP. We would them
> point people (now with a news item, for the long term provably a note to
> handbook to newcomers would be nice) to that file to configure their
> setups. The main advantages I see:
> - We will flood less summary.log ;)
> - The information to configure the package is always present while
> package is installed, now, if we remove merge produced logs, people will
> need to reemerge the package or read directly the ebuild
> 
> What do you think?

Bikeshedding ... would go with README.gentoo, because people are already 
used to looking for README files. Every time we can eliminate 
Gentoo-specific weirdness, we should.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
Analyst, RedMonk <http://redmonk.com/dberkholz/>

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[William Hubbs]

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

On Fri, Jan 04, 2013 at 11:34:59PM -0600, Donnie Berkholz wrote:
> On 10:26 Sat 22 Dec     , Pacho Ramos wrote:
> > Hello
> > 
> > After seeing:
> > https://bugs.gentoo.org/show_bug.cgi?id=440214
> > 
> > Looking to a lot of its blockers shows that we are using "elog" messages
> > for informing people about configuration (like pointing people to
> > external links to get proper way of configuring things, tell them to add
> > to some system groups...). I thought that maybe this kind of information
> > could be simply included in a canonical file under /usr/share/doc/
> > package dir called, for example, CONFIGURATION or SETUP. We would them
> > point people (now with a news item, for the long term provably a note to
> > handbook to newcomers would be nice) to that file to configure their
> > setups. The main advantages I see:
> > - We will flood less summary.log ;)
> > - The information to configure the package is always present while
> > package is installed, now, if we remove merge produced logs, people will
> > need to reemerge the package or read directly the ebuild
> > 
> > What do you think?
> 
> Bikeshedding ... would go with README.gentoo, because people are already 
> used to looking for README files. Every time we can eliminate 
> Gentoo-specific weirdness, we should.

Thinking about this, I tend to agree.  That way we can put the README
file in ${FILESDIR} and change it whenever we need to for different
versions of the package.

William

> 
> -- 
> Thanks,
> Donnie
> 
> Donnie Berkholz
> Council Member / Sr. Developer, Gentoo Linux <http://dberkholz.com>
> Analyst, RedMonk <http://redmonk.com/dberkholz/>



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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Ralph Sennhauser]

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

On Fri, 4 Jan 2013 23:34:59 -0600
Donnie Berkholz <dberkholz@gentoo.org> wrote:

> On 10:26 Sat 22 Dec     , Pacho Ramos wrote:
> > Hello
> > 
> > After seeing:
> > https://bugs.gentoo.org/show_bug.cgi?id=440214
> > 
> > Looking to a lot of its blockers shows that we are using "elog"
> > messages for informing people about configuration (like pointing
> > people to external links to get proper way of configuring things,
> > tell them to add to some system groups...). I thought that maybe
> > this kind of information could be simply included in a canonical
> > file under /usr/share/doc/ package dir called, for example,
> > CONFIGURATION or SETUP. We would them point people (now with a news
> > item, for the long term provably a note to handbook to newcomers
> > would be nice) to that file to configure their setups. The main
> > advantages I see:
> > - We will flood less summary.log ;)
> > - The information to configure the package is always present while
> > package is installed, now, if we remove merge produced logs, people
> > will need to reemerge the package or read directly the ebuild
> > 
> > What do you think?
> 
> Bikeshedding ... would go with README.gentoo, because people are
> already used to looking for README files. Every time we can eliminate 
> Gentoo-specific weirdness, we should.
> 

See the documentation for README.Debian[1], most importantly the
example. ;)

I'd say we should handle it the same as Debian does. What could we
possibly gain from doing it differently?

[1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/06/2013 01:04 AM, Ralph Sennhauser wrote:
> On Fri, 4 Jan 2013 23:34:59 -0600
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> 
>> On 10:26 Sat 22 Dec     , Pacho Ramos wrote:
>>> Hello
>>>
>>> After seeing:
>>> https://bugs.gentoo.org/show_bug.cgi?id=440214
>>>
>>> Looking to a lot of its blockers shows that we are using "elog"
>>> messages for informing people about configuration (like pointing
>>> people to external links to get proper way of configuring things,
>>> tell them to add to some system groups...). I thought that maybe
>>> this kind of information could be simply included in a canonical
>>> file under /usr/share/doc/ package dir called, for example,
>>> CONFIGURATION or SETUP. We would them point people (now with a news
>>> item, for the long term provably a note to handbook to newcomers
>>> would be nice) to that file to configure their setups. The main
>>> advantages I see:
>>> - We will flood less summary.log ;)
>>> - The information to configure the package is always present while
>>> package is installed, now, if we remove merge produced logs, people
>>> will need to reemerge the package or read directly the ebuild
>>>
>>> What do you think?
>>
>> Bikeshedding ... would go with README.gentoo, because people are
>> already used to looking for README files. Every time we can eliminate 
>> Gentoo-specific weirdness, we should.
>>
> 
> See the documentation for README.Debian[1], most importantly the
> example. ;)
> 
> I'd say we should handle it the same as Debian does.

README.gentoo sounds good to me.

> What could we possibly gain from doing it differently?

Does Debian have a postinst message, like the proposed eclass would
generate? Do you agree that a postinst message is desirable feature?

> [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme
> 
-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Michael Mol]

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

On Jan 6, 2013 8:32 PM, "Zac Medico" <zmedico@gentoo.org> wrote:
>
> On 01/06/2013 01:04 AM, Ralph Sennhauser wrote:
> > On Fri, 4 Jan 2013 23:34:59 -0600
> > Donnie Berkholz <dberkholz@gentoo.org> wrote:
> >
> >> On 10:26 Sat 22 Dec     , Pacho Ramos wrote:
> >>> Hello
> >>>
> >>> After seeing:
> >>> https://bugs.gentoo.org/show_bug.cgi?id=440214
> >>>
> >>> Looking to a lot of its blockers shows that we are using "elog"
> >>> messages for informing people about configuration (like pointing
> >>> people to external links to get proper way of configuring things,
> >>> tell them to add to some system groups...). I thought that maybe
> >>> this kind of information could be simply included in a canonical
> >>> file under /usr/share/doc/ package dir called, for example,
> >>> CONFIGURATION or SETUP. We would them point people (now with a news
> >>> item, for the long term provably a note to handbook to newcomers
> >>> would be nice) to that file to configure their setups. The main
> >>> advantages I see:
> >>> - We will flood less summary.log ;)
> >>> - The information to configure the package is always present while
> >>> package is installed, now, if we remove merge produced logs, people
> >>> will need to reemerge the package or read directly the ebuild
> >>>
> >>> What do you think?
> >>
> >> Bikeshedding ... would go with README.gentoo, because people are
> >> already used to looking for README files. Every time we can eliminate
> >> Gentoo-specific weirdness, we should.
> >>
> >
> > See the documentation for README.Debian[1], most importantly the
> > example. ;)
> >
> > I'd say we should handle it the same as Debian does.
>
> README.gentoo sounds good to me.
>
> > What could we possibly gain from doing it differently?
>
> Does Debian have a postinst message, like the proposed eclass would
> generate? Do you agree that a postinst message is desirable feature?
>
> > [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme
> >
> --
> Thanks,
> Zac
>

If we had README.gentoo, I'd love it if Portage alerted me as those files
changed.

[-- Attachment #2: Type: text/html, Size: 3062 bytes --]

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/06/2013 05:36 PM, Michael Mol wrote:
> 
> On Jan 6, 2013 8:32 PM, "Zac Medico" <zmedico@gentoo.org
> <mailto:zmedico@gentoo.org>> wrote:
>>
>> On 01/06/2013 01:04 AM, Ralph Sennhauser wrote:
>> > On Fri, 4 Jan 2013 23:34:59 -0600
>> > Donnie Berkholz <dberkholz@gentoo.org <mailto:dberkholz@gentoo.org>>
> wrote:
>> >
>> >> On 10:26 Sat 22 Dec     , Pacho Ramos wrote:
>> >>> Hello
>> >>>
>> >>> After seeing:
>> >>> https://bugs.gentoo.org/show_bug.cgi?id=440214
>> >>>
>> >>> Looking to a lot of its blockers shows that we are using "elog"
>> >>> messages for informing people about configuration (like pointing
>> >>> people to external links to get proper way of configuring things,
>> >>> tell them to add to some system groups...). I thought that maybe
>> >>> this kind of information could be simply included in a canonical
>> >>> file under /usr/share/doc/ package dir called, for example,
>> >>> CONFIGURATION or SETUP. We would them point people (now with a news
>> >>> item, for the long term provably a note to handbook to newcomers
>> >>> would be nice) to that file to configure their setups. The main
>> >>> advantages I see:
>> >>> - We will flood less summary.log ;)
>> >>> - The information to configure the package is always present while
>> >>> package is installed, now, if we remove merge produced logs, people
>> >>> will need to reemerge the package or read directly the ebuild
>> >>>
>> >>> What do you think?
>> >>
>> >> Bikeshedding ... would go with README.gentoo, because people are
>> >> already used to looking for README files. Every time we can eliminate
>> >> Gentoo-specific weirdness, we should.
>> >>
>> >
>> > See the documentation for README.Debian[1], most importantly the
>> > example. ;)
>> >
>> > I'd say we should handle it the same as Debian does.
>>
>> README.gentoo sounds good to me.
>>
>> > What could we possibly gain from doing it differently?
>>
>> Does Debian have a postinst message, like the proposed eclass would
>> generate? Do you agree that a postinst message is desirable feature?
>>
>> > [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme
>> >
>> --
>> Thanks,
>> Zac
>>
> 
> If we had README.gentoo, I'd love it if Portage alerted me as those
> files changed.

Even if it's just whitespace or formatting changes? Maybe it's better to
let the ebuild do version comparisons and decide whether to generate a
message based on that.
-- 
Thanks,
Zac

[gentoo-dev] Re: About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Duncan]

Michael Mol posted on Sun, 06 Jan 2013 20:36:00 -0500 as excerpted:

> If we had README.gentoo, I'd love it if Portage alerted me as those
> files changed.

That should be simple enough, provided that the files are installed with 
a package.  Simply config-protect README.gentoo, and you'd deal with 
changes the same way you deal with any config-protect change. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

[-- Attachment #1.1: Type: text/plain, Size: 2227 bytes --]

El vie, 04-01-2013 a las 23:34 -0600, Donnie Berkholz escribió:
> On 10:26 Sat 22 Dec     , Pacho Ramos wrote:
> > Hello
> > 
> > After seeing:
> > https://bugs.gentoo.org/show_bug.cgi?id=440214
> > 
> > Looking to a lot of its blockers shows that we are using "elog" messages
> > for informing people about configuration (like pointing people to
> > external links to get proper way of configuring things, tell them to add
> > to some system groups...). I thought that maybe this kind of information
> > could be simply included in a canonical file under /usr/share/doc/
> > package dir called, for example, CONFIGURATION or SETUP. We would them
> > point people (now with a news item, for the long term provably a note to
> > handbook to newcomers would be nice) to that file to configure their
> > setups. The main advantages I see:
> > - We will flood less summary.log ;)
> > - The information to configure the package is always present while
> > package is installed, now, if we remove merge produced logs, people will
> > need to reemerge the package or read directly the ebuild
> > 
> > What do you think?
> 
> Bikeshedding ... would go with README.gentoo, because people are already 
> used to looking for README files. Every time we can eliminate 
> Gentoo-specific weirdness, we should.
> 

This will install a README.gentoo file

But there are still pending issues I don't know how to handle:
- Eclass was originally oriented to cover those kind of messages that
could be shown by elog first time the package is merged and, later, rely
on people reading that README.gentoo
- William asked for version checking support, in that case, what kind of
version checking should be covered?
- Should I rely on versionator.eclass or use ">/<"? I can see both forms
in the tree right now
- There are also a lot of "exotic" version checkings in the tree (please
grep looking for REPLACING_VERSIONS to see them) that I doubt we should
cover in eclass but, in that case, how to cover them also?
- A suggestion about looking for "${FILESDIR}/README.gentoo" has also
raised, in that case, should eclass look for either option (now
DOC_CONTENTS variable or "${FILESDIR}/README.gentoo")


[-- Attachment #1.2: configuration-doc.eclass --]
[-- Type: text/plain, Size: 3012 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: configuration-doc
# @MAINTAINER:
# Pacho Ramos <pacho@gentoo.org>
# @AUTHOR:
# Author: Pacho Ramos <pacho@gentoo.org>
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips           
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}

if [[ ${___ECLASS_ONCE_CONFIGURATION_DOC} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_CONFIGURATION_DOC="recur -_+^+_- spank"

inherit eutils

case "${EAPI:-0}" in
	0|1|2|3)
		die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
		;;
	4|5)
		# EAPI>=4 is required for REPLACING_VERSIONS preventing us
		# from needing to export another pkg_preinst phase to save has_version
		# result. Also relies on EAPI >=4 default src_install phase.
		;;
	*)
		die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
		;;
esac

EXPORT_FUNCTIONS src_install pkg_postinst

# @FUNCTION: configuration_create_doc
# @DESCRIPTION:
# Create doc file with DOC_CONTENTS contents.
# Usually called at src_install phase.
configuration_create_doc() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -n "${DOC_CONTENTS}" ]]; then
		eshopts_push
		set -f
		echo ${DOC_CONTENTS} | fmt > "${T}"/README.gentoo
		eshopts_pop
		dodoc "${T}"/README.gentoo
	fi
}

# @FUNCTION: configuration_print_elog
# @DESCRIPTION:
# Print elog messages with DOC_CONTENTS contents.
# Usually called at pkg_postinst phase.
configuration_print_elog() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -n "${DOC_CONTENTS}" ]]; then
		if ! [[ "${REPLACING_VERSIONS}" ]]; then
			eshopts_push
			set -f
			if [ -f "${T}"/README.gentoo ]; then
				echo ${DOC_CONTENTS} | fmt | while read -r ELINE; do elog "${ELINE}"; done
			else
				die ""${T}"/README.gentoo is missing, did you forget to call configuration_create_doc function?"
			fi
			eshopts_pop
		fi
	fi
}


# @FUNCTION: configuration-doc_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
configuration-doc_src_install() {
	debug-print-function ${FUNCNAME} "${@}"

	default
	configuration_create_doc
}

# @FUNCTION: configuration-doc_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
configuration-doc_pkg_postinst() {
	debug-print-function ${FUNCNAME} "${@}"
	configuration_print_elog
}

fi

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Amadeusz Żołnowski]

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

Hi,

Quoting Pacho Ramos (2013-01-07 10:34:52)
> - Eclass was originally oriented to cover those kind of messages that
> could be shown by elog first time the package is merged and, later,
> rely on people reading that README.gentoo

This would be good - show README.gentoo for first time, and treat it
with config-protect (as Duncan said somewhere) to be sure user is not
going to miss changes (which could be compared with dispatch-conf).

> - William asked for version checking support, in that case, what kind
> of version checking should be covered?
> - There are also a lot of "exotic" version checkings in the tree
> (please grep looking for REPLACING_VERSIONS to see them) that I doubt
> we should cover in eclass but, in that case, how to cover them also?

README.gentoo could have only common info wrt package.  Things like
alerts that one should reemerge package because of update (which MUST be
checked with REPLACING_VERSIONS to avoid forcing users to check once
again if he/she is really updating from that version which is pretty
annoying).

> - A suggestion about looking for "${FILESDIR}/README.gentoo" has also
> raised, in that case, should eclass look for either option (now
> DOC_CONTENTS variable or "${FILESDIR}/README.gentoo")

"${FILESDIR}/README.gentoo" seems to be most reasonable place since this
file is going to be installed.  Putting it next to metadata.xml and
ChangeLog kills the idea, because of no easy way to see diff.


Regards,

-- 
Amadeusz Żołnowski

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAABAgAGBQJQ6yYxAAoJEPATRTHh2/q18eMIAJla4iKVszclgiI/dDnzoqFa
XCp0YX7MObAeVin0dd9pOmvteq07c9QWQYHXjzw2QYRWlG2eRGy2xMAe9AozeSSN
GHzv2bTjc8l7MoBuoJdtHesrWiHG70eNTN0t5mcStnGwq9MlbV71cN7+vZb1RgT3
Zd0ZNT/Tz4KsdoRbyX0LP2VXJuwaBE3iIKKgVQy2dkEfx+pHTl1VAHxIUkY28sak
yfScsTaLsh/OWOesHc6+qG/JlS0By5OkM5I3QjN06eyh+Vw7zBoRqgzDMupn5KpW
2pZJfixPT0fXlq8a4dopw7W4SeG/9mS/u6k8dhVLHVLx1/Mjf6bPuIRDrbzd2Kc=
=fNsH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2013 11:46 AM, Amadeusz Żołnowski wrote:
> Hi,
> 
> Quoting Pacho Ramos (2013-01-07 10:34:52)
>> - Eclass was originally oriented to cover those kind of messages
>> that could be shown by elog first time the package is merged and,
>> later, rely on people reading that README.gentoo
> 
> This would be good - show README.gentoo for first time, and treat
> it with config-protect (as Duncan said somewhere) to be sure user
> is not going to miss changes (which could be compared with
> dispatch-conf).

Maybe something similar to CONFIG_PROTECT is desirable, but it's not
exactly the same. The main differences are that the user will always
want to accept changes to README.gentoo, and the user will not be
interested in trivial formatting changes to README.gentoo. If
README.gentoo contained a version number that the package manager
could parse, then the package manager could detect when the version
number is bumped (indicating a non-trivial change).
- -- 
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDrc5IACgkQ/ejvha5XGaNPTACg1w1FGrSm+JAG4otnmRT5iIvu
DycAoPLCmR8223UH7zzD4HfQ7TiRJWQs
=idLH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Michael Mol]

On Sun, Jan 6, 2013 at 8:54 PM, Zac Medico <zmedico@gentoo.org> wrote:
> On 01/06/2013 05:36 PM, Michael Mol wrote:
>>
>> On Jan 6, 2013 8:32 PM, "Zac Medico" <zmedico@gentoo.org
>> <mailto:zmedico@gentoo.org>> wrote:
>>>
>>> On 01/06/2013 01:04 AM, Ralph Sennhauser wrote:
>>> > On Fri, 4 Jan 2013 23:34:59 -0600
>>> > Donnie Berkholz <dberkholz@gentoo.org <mailto:dberkholz@gentoo.org>>
>> wrote:
>>> >
>>> >> On 10:26 Sat 22 Dec     , Pacho Ramos wrote:
>>> >>> Hello
>>> >>>
>>> >>> After seeing:
>>> >>> https://bugs.gentoo.org/show_bug.cgi?id=440214
>>> >>>
>>> >>> Looking to a lot of its blockers shows that we are using "elog"
>>> >>> messages for informing people about configuration (like pointing
>>> >>> people to external links to get proper way of configuring things,
>>> >>> tell them to add to some system groups...). I thought that maybe
>>> >>> this kind of information could be simply included in a canonical
>>> >>> file under /usr/share/doc/ package dir called, for example,
>>> >>> CONFIGURATION or SETUP. We would them point people (now with a news
>>> >>> item, for the long term provably a note to handbook to newcomers
>>> >>> would be nice) to that file to configure their setups. The main
>>> >>> advantages I see:
>>> >>> - We will flood less summary.log ;)
>>> >>> - The information to configure the package is always present while
>>> >>> package is installed, now, if we remove merge produced logs, people
>>> >>> will need to reemerge the package or read directly the ebuild
>>> >>>
>>> >>> What do you think?
>>> >>
>>> >> Bikeshedding ... would go with README.gentoo, because people are
>>> >> already used to looking for README files. Every time we can eliminate
>>> >> Gentoo-specific weirdness, we should.
>>> >>
>>> >
>>> > See the documentation for README.Debian[1], most importantly the
>>> > example. ;)
>>> >
>>> > I'd say we should handle it the same as Debian does.
>>>
>>> README.gentoo sounds good to me.
>>>
>>> > What could we possibly gain from doing it differently?
>>>
>>> Does Debian have a postinst message, like the proposed eclass would
>>> generate? Do you agree that a postinst message is desirable feature?
>>>
>>> > [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme
>>> >
>>> --
>>> Thanks,
>>> Zac
>>>
>>
>> If we had README.gentoo, I'd love it if Portage alerted me as those
>> files changed.
>
> Even if it's just whitespace or formatting changes? Maybe it's better to
> let the ebuild do version comparisons and decide whether to generate a
> message based on that.

I see two solutions to that:

1) Define a format for the file, so that substantive difference can be
programmatically discerned from non-substantive differences. I don't
have a good proposal for a particular format.

2) Make it so that an author of a README.gentoo file is well aware
that any change he makes will potentially annoy all his users if the
change isn't substantive.

Frankly, (2) seems entirely reasonable. And at the same time, being
able to look at version history for README.gentoo files would be
extraordinarily enlightening.

--
:wq

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/07/2013 05:35 PM, Michael Mol wrote:
> On Sun, Jan 6, 2013 at 8:54 PM, Zac Medico <zmedico@gentoo.org> wrote:
>> On 01/06/2013 05:36 PM, Michael Mol wrote:
>>>
>>> On Jan 6, 2013 8:32 PM, "Zac Medico" <zmedico@gentoo.org
>>> <mailto:zmedico@gentoo.org>> wrote:
>>>>
>>>> On 01/06/2013 01:04 AM, Ralph Sennhauser wrote:
>>>>> On Fri, 4 Jan 2013 23:34:59 -0600
>>>>> Donnie Berkholz <dberkholz@gentoo.org <mailto:dberkholz@gentoo.org>>
>>> wrote:
>>>>>
>>>>>> On 10:26 Sat 22 Dec     , Pacho Ramos wrote:
>>>>>>> Hello
>>>>>>>
>>>>>>> After seeing:
>>>>>>> https://bugs.gentoo.org/show_bug.cgi?id=440214
>>>>>>>
>>>>>>> Looking to a lot of its blockers shows that we are using "elog"
>>>>>>> messages for informing people about configuration (like pointing
>>>>>>> people to external links to get proper way of configuring things,
>>>>>>> tell them to add to some system groups...). I thought that maybe
>>>>>>> this kind of information could be simply included in a canonical
>>>>>>> file under /usr/share/doc/ package dir called, for example,
>>>>>>> CONFIGURATION or SETUP. We would them point people (now with a news
>>>>>>> item, for the long term provably a note to handbook to newcomers
>>>>>>> would be nice) to that file to configure their setups. The main
>>>>>>> advantages I see:
>>>>>>> - We will flood less summary.log ;)
>>>>>>> - The information to configure the package is always present while
>>>>>>> package is installed, now, if we remove merge produced logs, people
>>>>>>> will need to reemerge the package or read directly the ebuild
>>>>>>>
>>>>>>> What do you think?
>>>>>>
>>>>>> Bikeshedding ... would go with README.gentoo, because people are
>>>>>> already used to looking for README files. Every time we can eliminate
>>>>>> Gentoo-specific weirdness, we should.
>>>>>>
>>>>>
>>>>> See the documentation for README.Debian[1], most importantly the
>>>>> example. ;)
>>>>>
>>>>> I'd say we should handle it the same as Debian does.
>>>>
>>>> README.gentoo sounds good to me.
>>>>
>>>>> What could we possibly gain from doing it differently?
>>>>
>>>> Does Debian have a postinst message, like the proposed eclass would
>>>> generate? Do you agree that a postinst message is desirable feature?
>>>>
>>>>> [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme
>>>>>
>>>> --
>>>> Thanks,
>>>> Zac
>>>>
>>>
>>> If we had README.gentoo, I'd love it if Portage alerted me as those
>>> files changed.
>>
>> Even if it's just whitespace or formatting changes? Maybe it's better to
>> let the ebuild do version comparisons and decide whether to generate a
>> message based on that.
> 
> I see two solutions to that:
> 
> 1) Define a format for the file, so that substantive difference can be
> programmatically discerned from non-substantive differences. I don't
> have a good proposal for a particular format.

A version header that the package manager can parse, should do the trick.

> 2) Make it so that an author of a README.gentoo file is well aware
> that any change he makes will potentially annoy all his users if the
> change isn't substantive.

Frequent trivial modification should probably be avoided. OTOH, the
maintainer should not be ashamed of making occasion small modifications,
in order to improve the content quality.

> Frankly, (2) seems entirely reasonable. And at the same time, being
> able to look at version history for README.gentoo files would be
> extraordinarily enlightening.
> 
> --
> :wq
> 


-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

[-- Attachment #1.1: Type: text/plain, Size: 1140 bytes --]

El lun, 07-01-2013 a las 10:34 +0100, Pacho Ramos escribió:
[...]
> This will install a README.gentoo file
> 
> But there are still pending issues I don't know how to handle:
> - Eclass was originally oriented to cover those kind of messages that
> could be shown by elog first time the package is merged and, later, rely
> on people reading that README.gentoo
> - William asked for version checking support, in that case, what kind of
> version checking should be covered?
> - Should I rely on versionator.eclass or use ">/<"? I can see both forms
> in the tree right now
> - There are also a lot of "exotic" version checkings in the tree (please
> grep looking for REPLACING_VERSIONS to see them) that I doubt we should
> cover in eclass but, in that case, how to cover them also?
> - A suggestion about looking for "${FILESDIR}/README.gentoo" has also
> raised, in that case, should eclass look for either option (now
> DOC_CONTENTS variable or "${FILESDIR}/README.gentoo")
> 

This changes the name of eclass to readme.gentoo.eclass and gets
information from ${FILESDIR}/README.gentoo

Please take a look to it

[-- Attachment #1.2: readme.gentoo.eclass --]
[-- Type: text/x-readme, Size: 3121 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos <pacho@gentoo.org>
# @AUTHOR:
# Author: Pacho Ramos <pacho@gentoo.org>
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips           
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}

if [[ ${___ECLASS_ONCE_README_GENTOO} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_README_GENTOO="recur -_+^+_- spank"

inherit eutils

case "${EAPI:-0}" in
	0|1|2|3)
		die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
		;;
	4|5)
		# EAPI>=4 is required for REPLACING_VERSIONS preventing us
		# from needing to export another pkg_preinst phase to save has_version
		# result. Also relies on EAPI >=4 default src_install phase.
		;;
	*)
		die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
		;;
esac

EXPORT_FUNCTIONS src_install pkg_postinst

# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with "${FILESDIR}/README.gentoo" contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -f "${FILESDIR}/README.gentoo" ]]; then
		touch "${T}"/README.gentoo.src_install
		dodoc "${FILESDIR}/README.gentoo"
	else
		die "${FILESDIR}/README.gentoo doesn't exist!"
	fi
}

# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with DOC_CONTENTS contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -f "${FILESDIR}/README.gentoo" ]]; then
		if ! [[ "${REPLACING_VERSIONS}" ]]; then
			eshopts_push
			set -f
			if [ -f "${T}"/README.gentoo.src_install ]; then
				cat "${FILESDIR}/README.gentoo" | fmt | while read -r ELINE; do elog "${ELINE}"; done
			else
				die "${T}/README.gentoo.src_install is missing, did you forget to call readme.gentoo_create_doc function?"
			fi
			eshopts_pop
		fi
	else
		die "${FILESDIR}/README.gentoo doesn't exist!"
	fi
}


# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_src_install() {
	debug-print-function ${FUNCNAME} "${@}"

	default
	readme.gentoo_create_doc
}

# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_pkg_postinst() {
	debug-print-function ${FUNCNAME} "${@}"
	readme.gentoo_print_elog
}

fi

[-- Attachment #1.3: acpid-2.0.17.ebuild --]
[-- Type: text/plain, Size: 1454 bytes --]

# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-power/acpid/acpid-2.0.17.ebuild,v 1.7 2013/01/03 12:59:15 miska Exp $

EAPI=4
inherit systemd readme.gentoo

DESCRIPTION="Daemon for Advanced Configuration and Power Interface"
HOMEPAGE="http://tedfelix.com/linux/acpid-netlink.html"
SRC_URI="http://tedfelix.com/linux/${P}.tar.xz"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="amd64 ia64 -ppc x86"
IUSE="selinux"

RDEPEND="selinux? ( sec-policy/selinux-apm )"
DEPEND="${RDEPEND}"

src_configure() {
	econf --docdir=/usr/share/doc/${PF}
}

src_install() {
	emake DESTDIR="${D}" install

	newdoc kacpimon/README README.kacpimon
	dodoc -r samples
	rm -f "${D}"/usr/share/doc/${PF}/COPYING

	exeinto /etc/acpi
	newexe "${FILESDIR}"/${PN}-1.0.6-default.sh default.sh
	insinto /etc/acpi/events
	newins "${FILESDIR}"/${PN}-1.0.4-default default

	newinitd "${FILESDIR}"/${PN}-2.0.16-init.d ${PN}
	newconfd "${FILESDIR}"/${PN}-2.0.16-conf.d ${PN}

	systemd_dounit "${FILESDIR}"/systemd/${PN}.{service,socket}

	readme.gentoo_create_doc
}

pkg_postinst() {
	readme.gentoo_pkg_postinst

	# files/systemd/acpid.socket -> ListenStream=/run/acpid.socket
	mkdir -p "${ROOT}"/run

	if ! grep -qs "^tmpfs.*/run " "${ROOT}"/proc/mounts ; then
		echo
		ewarn "You should reboot the system now to get /run mounted with tmpfs!"
	fi
}

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/09/2013 11:53 AM, Pacho Ramos wrote:
> This changes the name of eclass to readme.gentoo.eclass and gets
> information from ${FILESDIR}/README.gentoo

What if there are multiple versions/slots that have different
README.gentoo content? Maybe the eclass should accommodate that somehow?
-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
> On 01/09/2013 11:53 AM, Pacho Ramos wrote:
> > This changes the name of eclass to readme.gentoo.eclass and gets
> > information from ${FILESDIR}/README.gentoo
> 
> What if there are multiple versions/slots that have different
> README.gentoo content? Maybe the eclass should accommodate that somehow?

I would go for versioning it as "${FILESDIR}"/README.gentoo-${PV} but,
in that case, I wouldn't know how to make it pick "major"
README.gentoo-${PV} to prevent people from needing to have one
README.gentoo-${PV} per version :S


Different slots shouldn't need any special handling as their docs should
be installed in their docdir/${PF}

But the anterior "variable idea" looks to solve this problem much
better :|

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El mié, 09-01-2013 a las 22:15 +0100, Pacho Ramos escribió:
> El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
> > On 01/09/2013 11:53 AM, Pacho Ramos wrote:
> > > This changes the name of eclass to readme.gentoo.eclass and gets
> > > information from ${FILESDIR}/README.gentoo
> > 
> > What if there are multiple versions/slots that have different
> > README.gentoo content? Maybe the eclass should accommodate that somehow?
> 
> I would go for versioning it as "${FILESDIR}"/README.gentoo-${PV} but,
> in that case, I wouldn't know how to make it pick "major"
> README.gentoo-${PV} to prevent people from needing to have one
> README.gentoo-${PV} per version :S
> 
> 
> Different slots shouldn't need any special handling as their docs should
> be installed in their docdir/${PF}
> 
> But the anterior "variable idea" looks to solve this problem much
> better :|

Maybe the best option would be to:
1. At first look for variable in ebuild
2. If not set, look for ${FILESDIR}/README.gentoo


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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

[-- Attachment #1.1: Type: text/plain, Size: 498 bytes --]

El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
> On 01/09/2013 11:53 AM, Pacho Ramos wrote:
> > This changes the name of eclass to readme.gentoo.eclass and gets
> > information from ${FILESDIR}/README.gentoo
> 
> What if there are multiple versions/slots that have different
> README.gentoo content? Maybe the eclass should accommodate that somehow?

This should work, it will read DOC_CONTENTS variable from ebuild and, if
not set, rely on common ${FILESDIR}/README.gentoo

[-- Attachment #1.2: readme.gentoo.eclass --]
[-- Type: text/x-readme, Size: 3179 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos <pacho@gentoo.org>
# @AUTHOR:
# Author: Pacho Ramos <pacho@gentoo.org>
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips           
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}

if [[ ${___ECLASS_ONCE_README_GENTOO} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_README_GENTOO="recur -_+^+_- spank"

inherit eutils

case "${EAPI:-0}" in
	0|1|2|3)
		die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
		;;
	4|5)
		# EAPI>=4 is required for REPLACING_VERSIONS preventing us
		# from needing to export another pkg_preinst phase to save has_version
		# result. Also relies on EAPI >=4 default src_install phase.
		;;
	*)
		die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
		;;
esac

EXPORT_FUNCTIONS src_install pkg_postinst

# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# with "${FILESDIR}/README.gentoo" contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -n "${DOC_CONTENTS}" ]]; then
		eshopts_push
		set -f
		echo ${DOC_CONTENTS} | fmt > "${T}"/README.gentoo
		eshopts_pop
		dodoc "${T}"/README.gentoo
	else
		if [[ -f "${FILESDIR}/README.gentoo" ]]; then
			cp "${FILESDIR}/README.gentoo" "${T}"/README.gentoo
			dodoc "${T}"/README.gentoo
		else
			die "You are not specifying README.gentoo contents!"
		fi
	fi
}

# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with "${T}"/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -f "${T}"/README.gentoo ]]; then
		if ! [[ "${REPLACING_VERSIONS}" ]]; then
			eshopts_push
			set -f
			cat "${T}"/README.gentoo | fmt | while read -r ELINE; do elog "${ELINE}"; done
			eshopts_pop
		fi
	else
		die "README.gentoo wasn't created at src_install!"
	fi
}


# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_src_install() {
	debug-print-function ${FUNCNAME} "${@}"

	default
	readme.gentoo_create_doc
}

# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_pkg_postinst() {
	debug-print-function ${FUNCNAME} "${@}"
	readme.gentoo_print_elog
}

fi

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/12/2013 01:46 AM, Pacho Ramos wrote:
> El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
>> On 01/09/2013 11:53 AM, Pacho Ramos wrote:
>>> This changes the name of eclass to readme.gentoo.eclass and gets
>>> information from ${FILESDIR}/README.gentoo
>>
>> What if there are multiple versions/slots that have different
>> README.gentoo content? Maybe the eclass should accommodate that somehow?
> 
> This should work, it will read DOC_CONTENTS variable from ebuild and, if
> not set, rely on common ${FILESDIR}/README.gentoo

You might add a loop to search for a version-specific README.gentoo,
like this:

  file=
  for suffix in -${PV} -${PV}-${PR} "" ; do
	[[ -f ${FILESDIR}/README.gentoo${suffix} ]] && \
           file=${FILESDIR}/README.gentoo${suffix}  && break
  done
  if [[ ${file} ]] ; then
     cp "${file}" "${T}"/README.gentoo
     dodoc "${T}"/README.gentoo
  fi

-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El sáb, 12-01-2013 a las 02:01 -0800, Zac Medico escribió:
> On 01/12/2013 01:46 AM, Pacho Ramos wrote:
> > El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
> >> On 01/09/2013 11:53 AM, Pacho Ramos wrote:
> >>> This changes the name of eclass to readme.gentoo.eclass and gets
> >>> information from ${FILESDIR}/README.gentoo
> >>
> >> What if there are multiple versions/slots that have different
> >> README.gentoo content? Maybe the eclass should accommodate that somehow?
> > 
> > This should work, it will read DOC_CONTENTS variable from ebuild and, if
> > not set, rely on common ${FILESDIR}/README.gentoo
> 
> You might add a loop to search for a version-specific README.gentoo,
> like this:
> 
>   file=
>   for suffix in -${PV} -${PV}-${PR} "" ; do
> 	[[ -f ${FILESDIR}/README.gentoo${suffix} ]] && \
>            file=${FILESDIR}/README.gentoo${suffix}  && break
>   done
>   if [[ ${file} ]] ; then
>      cp "${file}" "${T}"/README.gentoo
>      dodoc "${T}"/README.gentoo
>   fi
> 

Thank for explaining me how to do that. The problem is that I doubt if
it would really be useful as we usually won't need whan README.gentoo
per version, only to update if for some special cases from time to
time :/

For example: foo-1.0 relies on common README.gentoo file, foo-1.1 adds
new feature and, then, would use README.gentoo-1.1 file... but foo-1.2
will probably use the same README.gentoo-1.1 file :|

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El sáb, 12-01-2013 a las 11:34 +0100, Pacho Ramos escribió:
[...]
> Thank for explaining me how to do that. The problem is that I doubt if
> it would really be useful as we usually won't need whan README.gentoo
> per version, only to update if for some special cases from time to
> time :/
[...]

whan -> one :S



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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/12/2013 02:34 AM, Pacho Ramos wrote:
> El sáb, 12-01-2013 a las 02:01 -0800, Zac Medico escribió:
>> On 01/12/2013 01:46 AM, Pacho Ramos wrote:
>>> El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
>>>> On 01/09/2013 11:53 AM, Pacho Ramos wrote:
>>>>> This changes the name of eclass to readme.gentoo.eclass and
>>>>> gets information from ${FILESDIR}/README.gentoo
>>>> 
>>>> What if there are multiple versions/slots that have
>>>> different README.gentoo content? Maybe the eclass should
>>>> accommodate that somehow?
>>> 
>>> This should work, it will read DOC_CONTENTS variable from
>>> ebuild and, if not set, rely on common
>>> ${FILESDIR}/README.gentoo
>> 
>> You might add a loop to search for a version-specific
>> README.gentoo, like this:
>> 
>> file= for suffix in -${PV} -${PV}-${PR} "" ; do [[ -f
>> ${FILESDIR}/README.gentoo${suffix} ]] && \ 
>> file=${FILESDIR}/README.gentoo${suffix}  && break done if [[
>> ${file} ]] ; then cp "${file}" "${T}"/README.gentoo dodoc
>> "${T}"/README.gentoo fi
>> 
> 
> Thank for explaining me how to do that. The problem is that I doubt
> if it would really be useful as we usually won't need whan
> README.gentoo per version, only to update if for some special cases
> from time to time :/
> 
> For example: foo-1.0 relies on common README.gentoo file, foo-1.1
> adds new feature and, then, would use README.gentoo-1.1 file... but
> foo-1.2 will probably use the same README.gentoo-1.1 file :|

Still, it maybe it would be reasonable to use a different
README.gentoo for each SLOT, it there's more than one? Maybe it makes
more sense to have another variable like DOC_CONTENTS, but have it
refer to a filename? Then you should have multiple revisions of an
ebuild refer to the same file, without having to have duplicate
CONTENTS settings.
- -- 
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlDxW8oACgkQ/ejvha5XGaNc+wCgiaOC7oLLxRvgrGIO9t4SbqTN
Vw8AoIx88SBpcrHAcBO9HhQaCyrtEf3A
=cHLC
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Ian Stakenvicius]

On 2013-01-12, at 7:49 AM, Zac Medico <zmedico@gentoo.org> wrote:

> 
> Still, it maybe it would be reasonable to use a different
> README.gentoo for each SLOT, it there's more than one?


especially since that means no special logic is necessary when cleaning them up on uninstall...

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

[-- Attachment #1.1: Type: text/plain, Size: 2109 bytes --]

El sáb, 12-01-2013 a las 04:49 -0800, Zac Medico escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/12/2013 02:34 AM, Pacho Ramos wrote:
> > El sáb, 12-01-2013 a las 02:01 -0800, Zac Medico escribió:
> >> On 01/12/2013 01:46 AM, Pacho Ramos wrote:
> >>> El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
> >>>> On 01/09/2013 11:53 AM, Pacho Ramos wrote:
> >>>>> This changes the name of eclass to readme.gentoo.eclass and
> >>>>> gets information from ${FILESDIR}/README.gentoo
> >>>> 
> >>>> What if there are multiple versions/slots that have
> >>>> different README.gentoo content? Maybe the eclass should
> >>>> accommodate that somehow?
> >>> 
> >>> This should work, it will read DOC_CONTENTS variable from
> >>> ebuild and, if not set, rely on common
> >>> ${FILESDIR}/README.gentoo
> >> 
> >> You might add a loop to search for a version-specific
> >> README.gentoo, like this:
> >> 
> >> file= for suffix in -${PV} -${PV}-${PR} "" ; do [[ -f
> >> ${FILESDIR}/README.gentoo${suffix} ]] && \ 
> >> file=${FILESDIR}/README.gentoo${suffix}  && break done if [[
> >> ${file} ]] ; then cp "${file}" "${T}"/README.gentoo dodoc
> >> "${T}"/README.gentoo fi
> >> 
> > 
> > Thank for explaining me how to do that. The problem is that I doubt
> > if it would really be useful as we usually won't need whan
> > README.gentoo per version, only to update if for some special cases
> > from time to time :/
> > 
> > For example: foo-1.0 relies on common README.gentoo file, foo-1.1
> > adds new feature and, then, would use README.gentoo-1.1 file... but
> > foo-1.2 will probably use the same README.gentoo-1.1 file :|
> 
> Still, it maybe it would be reasonable to use a different
> README.gentoo for each SLOT, it there's more than one? Maybe it makes
> more sense to have another variable like DOC_CONTENTS, but have it
> refer to a filename? Then you should have multiple revisions of an
> ebuild refer to the same file, without having to have duplicate
> CONTENTS settings.
> - -- 
> Thanks,
> Zac

What about this approach?

[-- Attachment #1.2: readme.gentoo.eclass --]
[-- Type: text/x-readme, Size: 3731 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos <pacho@gentoo.org>
# @AUTHOR:
# Author: Pacho Ramos <pacho@gentoo.org>
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips           
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}

if [[ ${___ECLASS_ONCE_README_GENTOO} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_README_GENTOO="recur -_+^+_- spank"

inherit eutils

case "${EAPI:-0}" in
	0|1|2|3)
		die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
		;;
	4|5)
		# EAPI>=4 is required for REPLACING_VERSIONS preventing us
		# from needing to export another pkg_preinst phase to save has_version
		# result. Also relies on EAPI >=4 default src_install phase.
		;;
	*)
		die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
		;;
esac

EXPORT_FUNCTIONS src_install pkg_postinst

# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# with "${FILESDIR}/README.gentoo" contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -n "${DOC_CONTENTS}" ]]; then
		eshopts_push
		set -f
		echo ${DOC_CONTENTS} | fmt > "${T}"/README.gentoo
		eshopts_pop
		dodoc "${T}"/README.gentoo
	else
		if [[ -f "${FILESDIR}/README.gentoo-${SLOT}" ]]; then
			cp "${FILESDIR}/README.gentoo-${SLOT}" "${T}"/README.gentoo
			dodoc "${T}"/README.gentoo
		else
			if [[ -f "${FILESDIR}/README.gentoo" ]]; then
				cp "${FILESDIR}/README.gentoo" "${T}"/README.gentoo
				dodoc "${T}"/README.gentoo
			else
				die "You are not specifying README.gentoo contents!"
			fi
		fi
	fi
}

# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with "${T}"/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -f "${FILESDIR}/README.gentoo-${SLOT}" ]]; then
		if [[ -f "${T}"/README.gentoo ]]; then
			if ! [[ "${REPLACING_VERSIONS}:${SLOT}" ]]; then
				eshopts_push
				set -f
				cat "${T}"/README.gentoo | fmt | while read -r ELINE; do elog "${ELINE}"; done
				eshopts_pop
			fi
		else
			die "README.gentoo wasn't created at src_install!"
		fi
	else
		if [[ -f "${T}"/README.gentoo ]]; then
			if ! [[ "${REPLACING_VERSIONS}" ]]; then
				eshopts_push
				set -f
				cat "${T}"/README.gentoo | fmt | while read -r ELINE; do elog "${ELINE}"; done
				eshopts_pop
			fi
		else
			die "README.gentoo wasn't created at src_install!"
		fi
	fi
}


# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_src_install() {
	debug-print-function ${FUNCNAME} "${@}"

	default
	readme.gentoo_create_doc
}

# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_pkg_postinst() {
	debug-print-function ${FUNCNAME} "${@}"
	readme.gentoo_print_elog
}

fi

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/13/2013 04:18 AM, Pacho Ramos wrote:
> What about this approach?

You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

[-- Attachment #1.1: Type: text/plain, Size: 322 bytes --]

El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
> On 01/13/2013 04:18 AM, Pacho Ramos wrote:
> > What about this approach?
> 
> You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
> don't care about the sub-slot and the slash would cause problems.

Thanks, updated eclass attached

[-- Attachment #1.2: readme.gentoo.eclass --]
[-- Type: text/x-readme, Size: 3743 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos <pacho@gentoo.org>
# @AUTHOR:
# Author: Pacho Ramos <pacho@gentoo.org>
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips           
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}

if [[ ${___ECLASS_ONCE_README_GENTOO} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_README_GENTOO="recur -_+^+_- spank"

inherit eutils

case "${EAPI:-0}" in
	0|1|2|3)
		die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
		;;
	4|5)
		# EAPI>=4 is required for REPLACING_VERSIONS preventing us
		# from needing to export another pkg_preinst phase to save has_version
		# result. Also relies on EAPI >=4 default src_install phase.
		;;
	*)
		die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
		;;
esac

EXPORT_FUNCTIONS src_install pkg_postinst

# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# with "${FILESDIR}/README.gentoo" contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -n "${DOC_CONTENTS}" ]]; then
		eshopts_push
		set -f
		echo ${DOC_CONTENTS} | fmt > "${T}"/README.gentoo
		eshopts_pop
		dodoc "${T}"/README.gentoo
	else
		if [[ -f "${FILESDIR}/README.gentoo-${SLOT%/*}" ]]; then
			cp "${FILESDIR}/README.gentoo-${SLOT%/*}" "${T}"/README.gentoo
			dodoc "${T}"/README.gentoo
		else
			if [[ -f "${FILESDIR}/README.gentoo" ]]; then
				cp "${FILESDIR}/README.gentoo" "${T}"/README.gentoo
				dodoc "${T}"/README.gentoo
			else
				die "You are not specifying README.gentoo contents!"
			fi
		fi
	fi
}

# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with "${T}"/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -f "${FILESDIR}/README.gentoo-${SLOT%/*}" ]]; then
		if [[ -f "${T}"/README.gentoo ]]; then
			if ! [[ "${REPLACING_VERSIONS}:${SLOT%/*}" ]]; then
				eshopts_push
				set -f
				cat "${T}"/README.gentoo | fmt | while read -r ELINE; do elog "${ELINE}"; done
				eshopts_pop
			fi
		else
			die "README.gentoo wasn't created at src_install!"
		fi
	else
		if [[ -f "${T}"/README.gentoo ]]; then
			if ! [[ "${REPLACING_VERSIONS}" ]]; then
				eshopts_push
				set -f
				cat "${T}"/README.gentoo | fmt | while read -r ELINE; do elog "${ELINE}"; done
				eshopts_pop
			fi
		else
			die "README.gentoo wasn't created at src_install!"
		fi
	fi
}


# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_src_install() {
	debug-print-function ${FUNCNAME} "${@}"

	default
	readme.gentoo_create_doc
}

# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_pkg_postinst() {
	debug-print-function ${FUNCNAME} "${@}"
	readme.gentoo_print_elog
}

fi

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/13/2013 04:59 AM, Pacho Ramos wrote:
> El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
>> On 01/13/2013 04:18 AM, Pacho Ramos wrote:
>>> What about this approach?
>>
>> You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
>> don't care about the sub-slot and the slash would cause problems.
> 
> Thanks, updated eclass attached
> 

Here are a few problems I see with readme.gentoo_print_elog:

1) contains duplication of code

2)  [[ -f "${FILESDIR}/README.gentoo-${SLOT%/*}" ]] condition seems
wrong, shouldn't it just use [[ -f "${T}"/README.gentoo ]] since the
file was copied to "${T}"/README.gentoo iby readme.gentoo_create_doc?

3) [[ "${REPLACING_VERSIONS}:${SLOT%/*}" ]] condition seems wrong
because SLOT is always non-empty and that means the condition is always
true.

-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El lun, 14-01-2013 a las 01:29 -0800, Zac Medico escribió:
> On 01/13/2013 04:59 AM, Pacho Ramos wrote:
> > El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
> >> On 01/13/2013 04:18 AM, Pacho Ramos wrote:
> >>> What about this approach?
> >>
> >> You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
> >> don't care about the sub-slot and the slash would cause problems.
> > 
> > Thanks, updated eclass attached
> > 
> 
> Here are a few problems I see with readme.gentoo_print_elog:
> 
> 1) contains duplication of code
> 
> 2)  [[ -f "${FILESDIR}/README.gentoo-${SLOT%/*}" ]] condition seems
> wrong, shouldn't it just use [[ -f "${T}"/README.gentoo ]] since the
> file was copied to "${T}"/README.gentoo iby readme.gentoo_create_doc?

Yeah, probably both can be merged as checking for PACKAGENAME:SLOT
should be enough, the problem is how to check it :S

> 
> 3) [[ "${REPLACING_VERSIONS}:${SLOT%/*}" ]] condition seems wrong
> because SLOT is always non-empty and that means the condition is always
> true.
> 

Is there a way to check if category/package_name:$SLOT was installed
before merging?

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/17/2013 07:17 AM, Pacho Ramos wrote:
> El lun, 14-01-2013 a las 01:29 -0800, Zac Medico escribió:
>> On 01/13/2013 04:59 AM, Pacho Ramos wrote:
>>> El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
>>>> On 01/13/2013 04:18 AM, Pacho Ramos wrote:
>>>>> What about this approach?
>>>>
>>>> You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
>>>> don't care about the sub-slot and the slash would cause problems.
>>>
>>> Thanks, updated eclass attached
>>>
>>
>> Here are a few problems I see with readme.gentoo_print_elog:
>>
>> 1) contains duplication of code
>>
>> 2)  [[ -f "${FILESDIR}/README.gentoo-${SLOT%/*}" ]] condition seems
>> wrong, shouldn't it just use [[ -f "${T}"/README.gentoo ]] since the
>> file was copied to "${T}"/README.gentoo iby readme.gentoo_create_doc?
> 
> Yeah, probably both can be merged as checking for PACKAGENAME:SLOT
> should be enough, the problem is how to check it :S
> 
>>
>> 3) [[ "${REPLACING_VERSIONS}:${SLOT%/*}" ]] condition seems wrong
>> because SLOT is always non-empty and that means the condition is always
>> true.
>>
> 
> Is there a way to check if category/package_name:$SLOT was installed
> before merging?

REPLACING_VERSIONS always refers to packages with identical SLOT to the
current package So, if ${REPLACING_VERSIONS} is non-empty, then the
current package replaces another package with identical SLOT.
-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

[-- Attachment #1.1: Type: text/plain, Size: 1061 bytes --]

El jue, 17-01-2013 a las 07:47 -0800, Zac Medico escribió:
[...]
> >> Here are a few problems I see with readme.gentoo_print_elog:
> >>
> >> 1) contains duplication of code
> >>
> >> 2)  [[ -f "${FILESDIR}/README.gentoo-${SLOT%/*}" ]] condition seems
> >> wrong, shouldn't it just use [[ -f "${T}"/README.gentoo ]] since the
> >> file was copied to "${T}"/README.gentoo iby readme.gentoo_create_doc?
> > 
> > Yeah, probably both can be merged as checking for PACKAGENAME:SLOT
> > should be enough, the problem is how to check it :S
> > 
> >>
> >> 3) [[ "${REPLACING_VERSIONS}:${SLOT%/*}" ]] condition seems wrong
> >> because SLOT is always non-empty and that means the condition is always
> >> true.
> >>
> > 
> > Is there a way to check if category/package_name:$SLOT was installed
> > before merging?
> 
> REPLACING_VERSIONS always refers to packages with identical SLOT to the
> current package So, if ${REPLACING_VERSIONS} is non-empty, then the
> current package replaces another package with identical SLOT.

Another try ;)


[-- Attachment #1.2: readme.gentoo.eclass --]
[-- Type: text/x-readme, Size: 3267 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos <pacho@gentoo.org>
# @AUTHOR:
# Author: Pacho Ramos <pacho@gentoo.org>
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips           
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}

if [[ ${___ECLASS_ONCE_README_GENTOO} != "recur -_+^+_- spank" ]] ; then
___ECLASS_ONCE_README_GENTOO="recur -_+^+_- spank"

inherit eutils

case "${EAPI:-0}" in
	0|1|2|3)
		die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
		;;
	4|5)
		# EAPI>=4 is required for REPLACING_VERSIONS preventing us
		# from needing to export another pkg_preinst phase to save has_version
		# result. Also relies on EAPI >=4 default src_install phase.
		;;
	*)
		die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
		;;
esac

EXPORT_FUNCTIONS src_install pkg_postinst

# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# look for "${FILESDIR}/README.gentoo" contents. You can use 
# ${FILESDIR}/README.gentoo-${SLOT} also.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -n "${DOC_CONTENTS}" ]]; then
		eshopts_push
		set -f
		echo ${DOC_CONTENTS} | fmt > "${T}"/README.gentoo
		eshopts_pop
		dodoc "${T}"/README.gentoo
	else
		if [[ -f "${FILESDIR}/README.gentoo-${SLOT%/*}" ]]; then
			cp "${FILESDIR}/README.gentoo-${SLOT%/*}" "${T}"/README.gentoo
			dodoc "${T}"/README.gentoo
		else
			if [[ -f "${FILESDIR}/README.gentoo" ]]; then
				cp "${FILESDIR}/README.gentoo" "${T}"/README.gentoo
				dodoc "${T}"/README.gentoo
			else
				die "You are not specifying README.gentoo contents!"
			fi
		fi
	fi
}

# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with "${T}"/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
	debug-print-function ${FUNCNAME} "${@}"

	if [[ -f "${T}"/README.gentoo ]]; then
		if ! [[ "${REPLACING_VERSIONS}" ]]; then
			eshopts_push
			set -f
			cat "${T}"/README.gentoo | while read -r ELINE; do elog "${ELINE}"; done
			eshopts_pop
		fi
	else
		die "README.gentoo wasn't created at src_install!"
	fi
}


# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Install generated doc file automatically.
readme.gentoo_src_install() {
	debug-print-function ${FUNCNAME} "${@}"
	default
	readme.gentoo_create_doc
}

# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from from just generated doc file.
readme.gentoo_pkg_postinst() {
	debug-print-function ${FUNCNAME} "${@}"
	readme.gentoo_print_elog
}

fi

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/17/2013 08:00 AM, Pacho Ramos wrote:
> Another try ;)

Looks good to me.
-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Ciaran McCreesh]

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

On Thu, 17 Jan 2013 07:47:18 -0800
Zac Medico <zmedico@gentoo.org> wrote:
> REPLACING_VERSIONS always refers to packages with identical SLOT to
> the current package

No it doesn't. If you have foo-1:a and foo-2:b installed, and then you
install foo-1:b, it replaces both 1:a and 2:b.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/01/13 11:00 AM, Pacho Ramos wrote:
> 
> Another try ;)
> 


There doesn't seem to be any logic here to check if the README.gentoo
that was previously installed has differed from the one that will be
installed (if they differ then the changes should be shown, no?)

I think logic similar to the following could be added to ensure this
occurs, though:

readme.gentoo_check_update() {
  if [[ "${REPLACING_VERSIONS}" ]] ; then
    if diff -q "${T}"/README.gentoo \
    "${EROOT}/usr/share/doc/${PF}"/README.gentoo &>/dev/null; then
      touch "${T}"/README.gentoo.show
    fi
  else
    touch "${T}"/README.gentoo.show
  fi
}

readme.gentoo_pkg_preinst() {
	debug-print-function ${FUNCNAME} "${@}"
	readme.gentoo_check_update
}

Then, export the pkg_preinst phase too, and and in
readme.gentoo_print_elog , swap the conditional
"! [[ ${REPLACING_VERSIONS} ]]" with "[[ -e ${T}/README.gentoo.show ]]"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF0EAREIAAYFAlD4LKoACgkQ2ugaI38ACPCRvwD/Ub4EBc4ypYgfSItCSXc+ma2C
nrNUySPoHE0Him8vwZkA+LXvVUCNYpwD+DRh/Q5wl5Le8yiDql5F3BuUN0EQU9g=
=JbM2
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El jue, 17-01-2013 a las 11:54 -0500, Ian Stakenvicius escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 17/01/13 11:00 AM, Pacho Ramos wrote:
> > 
> > Another try ;)
> > 
> 
> 
> There doesn't seem to be any logic here to check if the README.gentoo
> that was previously installed has differed from the one that will be
> installed (if they differ then the changes should be shown, no?)

Didn't think in this feature :/

> 
> I think logic similar to the following could be added to ensure this
> occurs, though:
> 
> readme.gentoo_check_update() {
>   if [[ "${REPLACING_VERSIONS}" ]] ; then
>     if diff -q "${T}"/README.gentoo \
>     "${EROOT}/usr/share/doc/${PF}"/README.gentoo &>/dev/null; then

How could we handle different compressors people can use? Depending on
that README.gentoo will change its name ending with gz, bz2, xz... Maybe
we could use "README.gentoo*"...


>       touch "${T}"/README.gentoo.show
>     fi
>   else
>     touch "${T}"/README.gentoo.show
>   fi
> }
> 
> readme.gentoo_pkg_preinst() {
> 	debug-print-function ${FUNCNAME} "${@}"
> 	readme.gentoo_check_update
> }
> 
> Then, export the pkg_preinst phase too, and and in
> readme.gentoo_print_elog , swap the conditional
> "! [[ ${REPLACING_VERSIONS} ]]" with "[[ -e ${T}/README.gentoo.show ]]"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> 
> iF0EAREIAAYFAlD4LKoACgkQ2ugaI38ACPCRvwD/Ub4EBc4ypYgfSItCSXc+ma2C
> nrNUySPoHE0Him8vwZkA+LXvVUCNYpwD+DRh/Q5wl5Le8yiDql5F3BuUN0EQU9g=
> =JbM2
> -----END PGP SIGNATURE-----
> 
> 



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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/01/13 12:02 PM, Pacho Ramos wrote:
> 
>> How could we handle different compressors people can use? 
>> Depending on that README.gentoo will change its name ending with
>>  gz, bz2, xz... Maybe we could use "README.gentoo*"...
> 

Right; I didn't consider how the README.gentoo file might be
compressed by dodoc ..  OK, more logic required.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD4MM0ACgkQ2ugaI38ACPDbGgD9EpNcrTC7IfDRCUWA2vgVId/t
urKESESaRqH3Te6ujXYA/0wLaXOeNQJ8iMylQ4dy4XT5X9JGDB5+bneOM3MyadlM
=P6N8
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/01/13 11:47 AM, Ciaran McCreesh wrote:
> On Thu, 17 Jan 2013 07:47:18 -0800 Zac Medico <zmedico@gentoo.org>
> wrote:
>> REPLACING_VERSIONS always refers to packages with identical SLOT
>> to the current package
> 
> No it doesn't. If you have foo-1:a and foo-2:b installed, and then
> you install foo-1:b, it replaces both 1:a and 2:b.
> 

that would be an interesting case with portage, given if foo-1:a moved
to foo-1:b that should occur via a slot-move shouldn't it? and
therefore would end up conflicting with foo-2:b immediately.

This sort of limits said case to something that should never occur ...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD4MX4ACgkQ2ugaI38ACPC2LgEAi70mTJebnH54KiZR2+3BLvCS
5JXl8GDlogEohdqHZ4wA/2+Cs6I4HqAj7SzWbRMPu9u88PyW2Yg2tPyI0Acv/+/A
=bFTH
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 17 Jan 2013 12:14:38 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:
> On 17/01/13 11:47 AM, Ciaran McCreesh wrote:
> > On Thu, 17 Jan 2013 07:47:18 -0800 Zac Medico <zmedico@gentoo.org>
> > wrote:
> >> REPLACING_VERSIONS always refers to packages with identical SLOT
> >> to the current package
> > 
> > No it doesn't. If you have foo-1:a and foo-2:b installed, and then
> > you install foo-1:b, it replaces both 1:a and 2:b.
> > 
> 
> that would be an interesting case with portage, given if foo-1:a moved
> to foo-1:b that should occur via a slot-move shouldn't it?

There's nothing forcing that to be the case.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlD4MbkACgkQ96zL6DUtXhEuHgCeJhIsL1d8XofM6RAUCyXwgrPd
3o4AoJpCWOx4SjoMB/O/SfsQ+tl7VBjp
=doTo
-----END PGP SIGNATURE-----

[gentoo-dev] in-place SLOT updates on ebuilds?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/01/13 12:15 PM, Ciaran McCreesh wrote:
> Ian Stakenvicius <axs@gentoo.org> wrote:
>> On 17/01/13 11:47 AM, Ciaran McCreesh wrote:
>>> 
>>> .... If you have foo-1:a and foo-2:b installed, and then you
>>> install foo-1:b, it replaces both 1:a and 2:b.
>>> 
> 
>> that would be an interesting case with portage, given if foo-1:a
>> moved to foo-1:b that should occur via a slot-move shouldn't it?
> 
> There's nothing forcing that to be the case.
> 

Does an in-tree change in SLOT automatically schedule something for
rebuild on an emerge -uD (or equivalent command in other package
managers) ?  If so, does sub-slot changes also trigger this?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD4NBoACgkQ2ugaI38ACPAjrAD+JaecoYoJGj5hXFp5c1mSegFb
5P0RQcD4ariRVtycWYoA/3RpgyFO/HgMlR+JSHg5kuXe9GfwRdpq6SopHbHM1n/V
=y3wq
-----END PGP SIGNATURE-----

Re: [gentoo-dev] in-place SLOT updates on ebuilds?

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 17 Jan 2013 12:25:46 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:
> On 17/01/13 12:15 PM, Ciaran McCreesh wrote:
> > Ian Stakenvicius <axs@gentoo.org> wrote:
> >> On 17/01/13 11:47 AM, Ciaran McCreesh wrote:
> >>> 
> >>> .... If you have foo-1:a and foo-2:b installed, and then you
> >>> install foo-1:b, it replaces both 1:a and 2:b.
> >>> 
> > 
> >> that would be an interesting case with portage, given if foo-1:a
> >> moved to foo-1:b that should occur via a slot-move shouldn't it?
> > 
> > There's nothing forcing that to be the case.
> > 
> 
> Does an in-tree change in SLOT automatically schedule something for
> rebuild on an emerge -uD (or equivalent command in other package
> managers) ?  If so, does sub-slot changes also trigger this?

For Paludis, not necessarily (unless the user passes in -km or some
variation): we look at the slot of the best version in the tree, plus
the best version in the tree of each installed slot, and then compare
versions.

This is related to one of the reasons a revbump should be required when
moving a package from EAPI 4 to EAPI 5: if a package's version is
unchanged, then its slot changing from x to x/y isn't enough to force a
reinstall.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlD4NSAACgkQ96zL6DUtXhE92gCgh6sNJWx2ZlrkwGTpN4r5m60c
4zsAn2o29W+4n9AzT3fVcGbVZOZ3vP3a
=ZRrl
-----END PGP SIGNATURE-----

Re: [gentoo-dev] in-place SLOT updates on ebuilds?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/01/13 12:30 PM, Ciaran McCreesh wrote:
> On Thu, 17 Jan 2013 12:25:46 -0500 Ian Stakenvicius
> <axs@gentoo.org> wrote:
>> On 17/01/13 12:15 PM, Ciaran McCreesh wrote:
>>> Ian Stakenvicius <axs@gentoo.org> wrote:
>>>> On 17/01/13 11:47 AM, Ciaran McCreesh wrote:
>>>>> 
>>>>> .... If you have foo-1:a and foo-2:b installed, and then
>>>>> you install foo-1:b, it replaces both 1:a and 2:b.
>>>>> 
>>> 
>>>> that would be an interesting case with portage, given if
>>>> foo-1:a moved to foo-1:b that should occur via a slot-move
>>>> shouldn't it?
>>> 
>>> There's nothing forcing that to be the case.
>>> 
> 
>> Does an in-tree change in SLOT automatically schedule something
>> for rebuild on an emerge -uD (or equivalent command in other
>> package managers) ?  If so, does sub-slot changes also trigger
>> this?
> 
> For Paludis, not necessarily (unless the user passes in -km or
> some variation): we look at the slot of the best version in the
> tree, plus the best version in the tree of each installed slot, and
> then compare versions.
> 
> This is related to one of the reasons a revbump should be required
> when moving a package from EAPI 4 to EAPI 5: if a package's version
> is unchanged, then its slot changing from x to x/y isn't enough to
> force a reinstall.
> 

Makes sense.  Up until this point, I had assumed that an in-place SLOT
change wouldn't trigger a rebuild on a regular update.  I haddn't
considered that it might until you mentioned your example above.

Thanks for clarifying!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlD4OEcACgkQ2ugaI38ACPAeQAD/W7DUo1C4+xJRoArFflOqO/Sb
My2htCgqONtAl5gtan0BAKh2zoOy92HyisbBfvjYzoAkLrQa0kL8SUU4Pkdu18DU
=2Os5
-----END PGP SIGNATURE-----

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Zac Medico]

On 01/17/2013 08:47 AM, Ciaran McCreesh wrote:
> On Thu, 17 Jan 2013 07:47:18 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
>> REPLACING_VERSIONS always refers to packages with identical SLOT to
>> the current package
> 
> No it doesn't. If you have foo-1:a and foo-2:b installed, and then you
> install foo-1:b, it replaces both 1:a and 2:b.

Ah, that's true, because PMS constraints (and /var/db/pkg layout) force
foo-1:b to replace foo-1:a despite the difference in SLOT.

For the purposes of readme.gentoo.eclass though, the difference seems
negligible (foo-1:a and foo-1:b are likely to have mostly identical
README.gentoo content).
-- 
Thanks,
Zac

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El jue, 17-01-2013 a las 12:11 -0500, Ian Stakenvicius escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 17/01/13 12:02 PM, Pacho Ramos wrote:
> > 
> >> How could we handle different compressors people can use? 
> >> Depending on that README.gentoo will change its name ending with
> >>  gz, bz2, xz... Maybe we could use "README.gentoo*"...
> > 
> 
> Right; I didn't consider how the README.gentoo file might be
> compressed by dodoc ..  OK, more logic required.
> 

But, since it's compressed diff will always think it's different, then,
I am unsure if this could be implemented :|

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

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Pacho Ramos]

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

El jue, 17-01-2013 a las 08:31 -0800, Zac Medico escribió:
> On 01/17/2013 08:00 AM, Pacho Ramos wrote:
> > Another try ;)
> 
> Looks good to me.

+  20 Jan 2013; Pacho Ramos <pacho@gentoo.org> +readme.gentoo.eclass:
+  Finally commit readme.gentoo.eclass to create a README.gentoo doc
file
+  recording tips shown via elog messages first time the package is
merged.
+

About handling more exotic cases (like different tips per version),
please should set DOC_CONTENTS instead of relying in
${FILESDIR}/README.gentoo* files (that are harder to make as flexible as
all this cases would require)

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