* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-05 5:34 ` Donnie Berkholz
@ 2013-01-06 4:24 ` William Hubbs
2013-01-06 9:04 ` Ralph Sennhauser
2013-01-07 9:34 ` [gentoo-dev] " Pacho Ramos
2 siblings, 0 replies; 67+ messages in thread
From: William Hubbs @ 2013-01-06 4:24 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-05 5:34 ` Donnie Berkholz
2013-01-06 4:24 ` William Hubbs
@ 2013-01-06 9:04 ` Ralph Sennhauser
2013-01-07 1:30 ` Zac Medico
2013-01-07 9:34 ` [gentoo-dev] " Pacho Ramos
2 siblings, 1 reply; 67+ messages in thread
From: Ralph Sennhauser @ 2013-01-06 9:04 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-06 9:04 ` Ralph Sennhauser
@ 2013-01-07 1:30 ` Zac Medico
2013-01-07 1:36 ` Michael Mol
0 siblings, 1 reply; 67+ messages in thread
From: Zac Medico @ 2013-01-07 1:30 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-07 1:30 ` Zac Medico
@ 2013-01-07 1:36 ` Michael Mol
2013-01-07 1:54 ` Zac Medico
2013-01-07 4:08 ` [gentoo-dev] " Duncan
0 siblings, 2 replies; 67+ messages in thread
From: Michael Mol @ 2013-01-07 1:36 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-07 1:36 ` Michael Mol
@ 2013-01-07 1:54 ` Zac Medico
2013-01-08 1:35 ` Michael Mol
2013-01-07 4:08 ` [gentoo-dev] " Duncan
1 sibling, 1 reply; 67+ messages in thread
From: Zac Medico @ 2013-01-07 1:54 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-07 1:54 ` Zac Medico
@ 2013-01-08 1:35 ` Michael Mol
2013-01-08 1:56 ` Zac Medico
0 siblings, 1 reply; 67+ messages in thread
From: Michael Mol @ 2013-01-08 1:35 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-08 1:35 ` Michael Mol
@ 2013-01-08 1:56 ` Zac Medico
0 siblings, 0 replies; 67+ messages in thread
From: Zac Medico @ 2013-01-08 1:56 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 67+ messages in thread
* [gentoo-dev] Re: About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-07 1:36 ` Michael Mol
2013-01-07 1:54 ` Zac Medico
@ 2013-01-07 4:08 ` Duncan
1 sibling, 0 replies; 67+ messages in thread
From: Duncan @ 2013-01-07 4:08 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-05 5:34 ` Donnie Berkholz
2013-01-06 4:24 ` William Hubbs
2013-01-06 9:04 ` Ralph Sennhauser
@ 2013-01-07 9:34 ` Pacho Ramos
2013-01-07 19:46 ` Amadeusz Żołnowski
2013-01-09 19:53 ` Pacho Ramos
2 siblings, 2 replies; 67+ messages in thread
From: Pacho Ramos @ 2013-01-07 9:34 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-07 9:34 ` [gentoo-dev] " Pacho Ramos
@ 2013-01-07 19:46 ` Amadeusz Żołnowski
2013-01-08 1:17 ` Zac Medico
2013-01-09 19:53 ` Pacho Ramos
1 sibling, 1 reply; 67+ messages in thread
From: Amadeusz Żołnowski @ 2013-01-07 19:46 UTC (permalink / raw
To: Pacho Ramos; +Cc: gentoo-dev
[-- 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-----
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-07 19:46 ` Amadeusz Żołnowski
@ 2013-01-08 1:17 ` Zac Medico
0 siblings, 0 replies; 67+ messages in thread
From: Zac Medico @ 2013-01-08 1:17 UTC (permalink / raw
To: gentoo-dev, Pacho Ramos, Amadeusz Żołnowski
-----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-----
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-07 9:34 ` [gentoo-dev] " Pacho Ramos
2013-01-07 19:46 ` Amadeusz Żołnowski
@ 2013-01-09 19:53 ` Pacho Ramos
2013-01-09 20:04 ` Zac Medico
1 sibling, 1 reply; 67+ messages in thread
From: Pacho Ramos @ 2013-01-09 19:53 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-09 19:53 ` Pacho Ramos
@ 2013-01-09 20:04 ` Zac Medico
2013-01-09 21:15 ` Pacho Ramos
2013-01-12 9:46 ` Pacho Ramos
0 siblings, 2 replies; 67+ messages in thread
From: Zac Medico @ 2013-01-09 20:04 UTC (permalink / raw
To: gentoo-dev, Pacho Ramos
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
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-09 20:04 ` Zac Medico
@ 2013-01-09 21:15 ` Pacho Ramos
2013-01-09 21:29 ` Pacho Ramos
2013-01-12 9:46 ` Pacho Ramos
1 sibling, 1 reply; 67+ messages in thread
From: Pacho Ramos @ 2013-01-09 21:15 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-09 21:15 ` Pacho Ramos
@ 2013-01-09 21:29 ` Pacho Ramos
0 siblings, 0 replies; 67+ messages in thread
From: Pacho Ramos @ 2013-01-09 21:29 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-09 20:04 ` Zac Medico
2013-01-09 21:15 ` Pacho Ramos
@ 2013-01-12 9:46 ` Pacho Ramos
2013-01-12 10:01 ` Zac Medico
1 sibling, 1 reply; 67+ messages in thread
From: Pacho Ramos @ 2013-01-12 9:46 UTC (permalink / raw
To: Zac Medico; +Cc: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-12 9:46 ` Pacho Ramos
@ 2013-01-12 10:01 ` Zac Medico
2013-01-12 10:34 ` Pacho Ramos
0 siblings, 1 reply; 67+ messages in thread
From: Zac Medico @ 2013-01-12 10:01 UTC (permalink / raw
To: Pacho Ramos, gentoo-dev
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
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-12 10:01 ` Zac Medico
@ 2013-01-12 10:34 ` Pacho Ramos
2013-01-12 10:55 ` Pacho Ramos
2013-01-12 12:49 ` Zac Medico
0 siblings, 2 replies; 67+ messages in thread
From: Pacho Ramos @ 2013-01-12 10:34 UTC (permalink / raw
To: Zac Medico; +Cc: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-12 10:34 ` Pacho Ramos
@ 2013-01-12 10:55 ` Pacho Ramos
2013-01-12 12:49 ` Zac Medico
1 sibling, 0 replies; 67+ messages in thread
From: Pacho Ramos @ 2013-01-12 10:55 UTC (permalink / raw
To: gentoo-dev; +Cc: Zac Medico
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-12 10:34 ` Pacho Ramos
2013-01-12 10:55 ` Pacho Ramos
@ 2013-01-12 12:49 ` Zac Medico
2013-01-12 12:54 ` Ian Stakenvicius
2013-01-13 12:18 ` Pacho Ramos
1 sibling, 2 replies; 67+ messages in thread
From: Zac Medico @ 2013-01-12 12:49 UTC (permalink / raw
To: Pacho Ramos, gentoo-dev
-----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-----
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-12 12:49 ` Zac Medico
@ 2013-01-12 12:54 ` Ian Stakenvicius
2013-01-13 12:18 ` Pacho Ramos
1 sibling, 0 replies; 67+ messages in thread
From: Ian Stakenvicius @ 2013-01-12 12:54 UTC (permalink / raw
To: gentoo-dev@lists.gentoo.org
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...
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-12 12:49 ` Zac Medico
2013-01-12 12:54 ` Ian Stakenvicius
@ 2013-01-13 12:18 ` Pacho Ramos
2013-01-13 12:54 ` Zac Medico
1 sibling, 1 reply; 67+ messages in thread
From: Pacho Ramos @ 2013-01-13 12:18 UTC (permalink / raw
To: Zac Medico; +Cc: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-13 12:18 ` Pacho Ramos
@ 2013-01-13 12:54 ` Zac Medico
2013-01-13 12:59 ` Pacho Ramos
0 siblings, 1 reply; 67+ messages in thread
From: Zac Medico @ 2013-01-13 12:54 UTC (permalink / raw
To: Pacho Ramos, gentoo-dev
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
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-13 12:54 ` Zac Medico
@ 2013-01-13 12:59 ` Pacho Ramos
2013-01-14 9:29 ` Zac Medico
0 siblings, 1 reply; 67+ messages in thread
From: Pacho Ramos @ 2013-01-13 12:59 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-13 12:59 ` Pacho Ramos
@ 2013-01-14 9:29 ` Zac Medico
2013-01-17 15:17 ` Pacho Ramos
0 siblings, 1 reply; 67+ messages in thread
From: Zac Medico @ 2013-01-14 9:29 UTC (permalink / raw
To: gentoo-dev, Pacho Ramos
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
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-14 9:29 ` Zac Medico
@ 2013-01-17 15:17 ` Pacho Ramos
2013-01-17 15:47 ` Zac Medico
0 siblings, 1 reply; 67+ messages in thread
From: Pacho Ramos @ 2013-01-17 15:17 UTC (permalink / raw
To: Zac Medico; +Cc: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-17 15:17 ` Pacho Ramos
@ 2013-01-17 15:47 ` Zac Medico
2013-01-17 16:00 ` Pacho Ramos
2013-01-17 16:47 ` Ciaran McCreesh
0 siblings, 2 replies; 67+ messages in thread
From: Zac Medico @ 2013-01-17 15:47 UTC (permalink / raw
To: Pacho Ramos, gentoo-dev
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
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-17 15:47 ` Zac Medico
@ 2013-01-17 16:00 ` Pacho Ramos
2013-01-17 16:31 ` Zac Medico
2013-01-17 16:54 ` Ian Stakenvicius
2013-01-17 16:47 ` Ciaran McCreesh
1 sibling, 2 replies; 67+ messages in thread
From: Pacho Ramos @ 2013-01-17 16:00 UTC (permalink / raw
To: Zac Medico; +Cc: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-17 16:00 ` Pacho Ramos
@ 2013-01-17 16:31 ` Zac Medico
2013-01-20 11:43 ` Pacho Ramos
2013-01-17 16:54 ` Ian Stakenvicius
1 sibling, 1 reply; 67+ messages in thread
From: Zac Medico @ 2013-01-17 16:31 UTC (permalink / raw
To: Pacho Ramos; +Cc: gentoo-dev
On 01/17/2013 08:00 AM, Pacho Ramos wrote:
> Another try ;)
Looks good to me.
--
Thanks,
Zac
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-17 16:00 ` Pacho Ramos
2013-01-17 16:31 ` Zac Medico
@ 2013-01-17 16:54 ` Ian Stakenvicius
2013-01-17 17:02 ` Pacho Ramos
1 sibling, 1 reply; 67+ messages in thread
From: Ian Stakenvicius @ 2013-01-17 16:54 UTC (permalink / raw
To: gentoo-dev
-----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-----
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-17 16:54 ` Ian Stakenvicius
@ 2013-01-17 17:02 ` Pacho Ramos
2013-01-17 17:11 ` Ian Stakenvicius
0 siblings, 1 reply; 67+ messages in thread
From: Pacho Ramos @ 2013-01-17 17:02 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-17 17:02 ` Pacho Ramos
@ 2013-01-17 17:11 ` Ian Stakenvicius
2013-01-17 18:37 ` Pacho Ramos
0 siblings, 1 reply; 67+ messages in thread
From: Ian Stakenvicius @ 2013-01-17 17:11 UTC (permalink / raw
To: gentoo-dev
-----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-----
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-17 17:11 ` Ian Stakenvicius
@ 2013-01-17 18:37 ` Pacho Ramos
0 siblings, 0 replies; 67+ messages in thread
From: Pacho Ramos @ 2013-01-17 18:37 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-17 15:47 ` Zac Medico
2013-01-17 16:00 ` Pacho Ramos
@ 2013-01-17 16:47 ` Ciaran McCreesh
2013-01-17 17:14 ` Ian Stakenvicius
2013-01-17 17:57 ` [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information Zac Medico
1 sibling, 2 replies; 67+ messages in thread
From: Ciaran McCreesh @ 2013-01-17 16:47 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-17 16:47 ` Ciaran McCreesh
@ 2013-01-17 17:14 ` Ian Stakenvicius
2013-01-17 17:15 ` Ciaran McCreesh
2013-01-17 17:57 ` [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information Zac Medico
1 sibling, 1 reply; 67+ messages in thread
From: Ian Stakenvicius @ 2013-01-17 17:14 UTC (permalink / raw
To: gentoo-dev
-----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-----
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-17 17:14 ` Ian Stakenvicius
@ 2013-01-17 17:15 ` Ciaran McCreesh
2013-01-17 17:25 ` [gentoo-dev] in-place SLOT updates on ebuilds? Ian Stakenvicius
0 siblings, 1 reply; 67+ messages in thread
From: Ciaran McCreesh @ 2013-01-17 17:15 UTC (permalink / raw
To: gentoo-dev
-----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-----
^ permalink raw reply [flat|nested] 67+ messages in thread
* [gentoo-dev] in-place SLOT updates on ebuilds?
2013-01-17 17:15 ` Ciaran McCreesh
@ 2013-01-17 17:25 ` Ian Stakenvicius
2013-01-17 17:30 ` Ciaran McCreesh
0 siblings, 1 reply; 67+ messages in thread
From: Ian Stakenvicius @ 2013-01-17 17:25 UTC (permalink / raw
To: gentoo-dev
-----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-----
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] in-place SLOT updates on ebuilds?
2013-01-17 17:25 ` [gentoo-dev] in-place SLOT updates on ebuilds? Ian Stakenvicius
@ 2013-01-17 17:30 ` Ciaran McCreesh
2013-01-17 17:43 ` Ian Stakenvicius
0 siblings, 1 reply; 67+ messages in thread
From: Ciaran McCreesh @ 2013-01-17 17:30 UTC (permalink / raw
To: gentoo-dev
-----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-----
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] in-place SLOT updates on ebuilds?
2013-01-17 17:30 ` Ciaran McCreesh
@ 2013-01-17 17:43 ` Ian Stakenvicius
0 siblings, 0 replies; 67+ messages in thread
From: Ian Stakenvicius @ 2013-01-17 17:43 UTC (permalink / raw
To: gentoo-dev
-----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-----
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
2013-01-17 16:47 ` Ciaran McCreesh
2013-01-17 17:14 ` Ian Stakenvicius
@ 2013-01-17 17:57 ` Zac Medico
1 sibling, 0 replies; 67+ messages in thread
From: Zac Medico @ 2013-01-17 17:57 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 67+ messages in thread