Steve Long wrote:
> Thomas Sachau wrote: [...]
>
> > [[ -n ${DOCS} ]] && dodoc ${DOCS}
[...]
>
> It might be wise to use an array for DOCS there
Since I have now seen suggestions for using arrays unnecessarily
at least twice (see also
[RFC] Ability to pass arguments to src_configure/src_compil
On Sat, 20 Sep 2008 22:05:43 +0300
Petteri Räty <[EMAIL PROTECTED]> wrote:
> Alexis Ballier kirjoitti:
> > Hi,
> >
> >> When EAPI 2 goes live built_with_use should probably die for most
> >> cases.
> >
> > I don't understand here: you mean die like being removed or die like
> > the die call in
Petteri Räty schrieb:
> Thomas Sachau kirjoitti:
>> I see, we have a default src_unpack and a default src_compile but a
>> default src_install is still
>> missing. Here is my suggestion (taken and modified from bug 33544):
>>
>> src_install() {
>> if [ -f Makefile -o -f GNUmakefile -o -f makefi
Thomas Sachau kirjoitti:
I see, we have a default src_unpack and a default src_compile but a default
src_install is still
missing. Here is my suggestion (taken and modified from bug 33544):
src_install() {
if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
emake D
Alexis Ballier kirjoitti:
Hi,
When EAPI 2 goes live built_with_use should probably die for most
cases.
I don't understand here: you mean die like being removed or die like
the die call in an ebuild? If I understood correctly the following it
should be the latter.
Well we could go with eit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ryan Hill wrote:
> If a file overwritten by the second package falls under CONFIG_PROTECT,
> will portage treat it like a normal update?
Yes, it's normal in the sense that the merge logic behaves exactly
the same as it would for any other merge. The m
On Sun, 31 Aug 2008 15:38:43 -0700
Zac Medico <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi everyone,
>
> Please consider a blocker syntax extension, for inclusion in EAPI 2,
> which will serve to indicate that conflicting packages may be
> temporarily inst
On Sun, 07 Sep 2008 02:05:07 +
"Jorge Manuel B. S. Vicetto" <[EMAIL PROTECTED]> wrote:
> We've been trying to find a way that
> will allow users to do an FHS compliant install if they want it,
> while at the same time still allowing those that are not interested
> in it to keep using the curre
Hi,
> When EAPI 2 goes live built_with_use should probably die for most
> cases.
I don't understand here: you mean die like being removed or die like
the die call in an ebuild? If I understood correctly the following it
should be the latter.
> Are there valid use cases for built_with_use that a
I've masked app-office/ooqstart-gnome and app-office/oooqs for upcoming
removal in 30 days. Both packages are broken and haven't been maintained
upstream for ages. If you want a proper quickstarter for OpenOffice.org
use the one which has been provided with the source-based build of OOo
for quite s
When EAPI 2 goes live built_with_use should probably die for most cases.
Are there valid use cases for built_with_use that are not covered by the
use deps in EAPI 2? If there are we could add a switch like --noeapi2die
to it.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signa
Thomas Sachau wrote:
> I see, we have a default src_unpack and a default src_compile but a
> default src_install is still missing. Here is my suggestion (taken and
> modified from bug 33544):
>
> src_install() {
> if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
> emake DESTDIR=${D} inst
I see, we have a default src_unpack and a default src_compile but a default
src_install is still
missing. Here is my suggestion (taken and modified from bug 33544):
src_install() {
if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
emake DESTDIR=${D} install || die
13 matches
Mail list logo
