Tiziano Müller wrote:
> The only problem I see here is that either or ${T}/doc
> contains subdirs. So my proposal for the next EAPI is to allow dodoc and
> newdoc to operate on dirs. Which also gives the benefit to reduce this
> idiom:
> insinto /usr/share/doc/${PF}
> doins -r examples
> to:
> On Thu, 19 Feb 2009, Tiziano Müller wrote:
>> emake DESTDIR="${D}" docdir="${T}/doc"
>> dodoc "${T}/doc"
> should be dodoc "${T}/doc/*"
O.K., that looks better.
However, you still copy files around, for the sole purpose to enable
dodoc's "magic" side effect (which also is not mentioned in
Am Donnerstag, den 19.02.2009, 10:37 +0100 schrieb Ulrich Mueller:
> > On Thu, 19 Feb 2009, Tiziano Müller wrote:
>
> > Instead of breaking things you could have tried to come up with a
> > real solution.
>
> This could be said about the council's decision as well.
>
Right. Two seconds after
Am Donnerstag, den 19.02.2009, 11:00 +0100 schrieb Ulrich Mueller:
> > On Thu, 19 Feb 2009, Nirbheek Chauhan wrote:
>
> >> This will not work. dodoc operates only on files, not on directories.
>
> > Tiziano mentioned that later in the email. Perhaps you missed it?
>
> I didn't miss it. Read
Tiziano Müller wrote:
The only problem I see here is that either or ${T}/doc
contains subdirs. So my proposal for the next EAPI is to allow dodoc and
newdoc to operate on dirs. Which also gives the benefit to reduce this
idiom:
insinto /usr/share/doc/${PF}
doins -r examples
to:
dodoc examp
> On Thu, 19 Feb 2009, Nirbheek Chauhan wrote:
>> This will not work. dodoc operates only on files, not on directories.
> Tiziano mentioned that later in the email. Perhaps you missed it?
I didn't miss it. Read his message again:
>>> The only problem I see here is that either or
>>> ${T}/d
On Thu, Feb 19, 2009 at 3:07 PM, Ulrich Mueller wrote:
>> On Thu, 19 Feb 2009, Tiziano Müller wrote:
> This will not work. dodoc operates only on files, not on directories.
>
Tiziano mentioned that later in the email. Perhaps you missed it? He
proposed allowing dodoc to apply on directories a
> On Thu, 19 Feb 2009, Tiziano Müller wrote:
> Instead of breaking things you could have tried to come up with a
> real solution.
This could be said about the council's decision as well.
> [1]
> src_install() {
> emake DESTDIR="${D}" docdir="/usr/share/doc/${PF}"
> prepalldocs
> }
> (or
Am Mittwoch, den 18.02.2009, 03:22 -0500 schrieb Michael Sterrett:
> Patches welcome.
>
> On Wed, Feb 18, 2009 at 3:13 AM, Torsten Veller wrote:
> > * Michael Sterrett :
> >> I added a prepalldocs function to eutils.eclass to provide the
> >> functionality. It implements the
> >> behavior of the
Patches welcome.
On Wed, Feb 18, 2009 at 3:13 AM, Torsten Veller wrote:
> * Michael Sterrett :
>> I added a prepalldocs function to eutils.eclass to provide the
>> functionality. It implements the
>> behavior of the current stable sys-apps/portage-2.1.6.4.
>
> ecompressdir is more portage intern
* Michael Sterrett :
> I added a prepalldocs function to eutils.eclass to provide the
> functionality. It implements the
> behavior of the current stable sys-apps/portage-2.1.6.4.
ecompressdir is more portage internal than prepalldocs ever was.
This must be fixed.
11 matches
Mail list logo