On Dec 30, 2007 6:50 PM, Petteri Räty [EMAIL PROTECTED] wrote:
I have a script coming up that can remove virtual/libc dependencies from
ebuilds automatically but can this be done safely for all ebuilds are
are there ebuilds in system that really need this dep for stage building
etc?
FWIW:
I like the overall idea. I will comment the first proposed alternative
as this is the one that makes the most sense in my opinion.
Having one global use.xml where the default definitions are, and then using
metadata.xml for each package to override the USE flag definition.
With 's/default
On Mon, 31 Dec 2007 05:03:21 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
Ciaran McCreesh kirjoitti:
Is it legal for ebuilds to call has_version and friends in
parallel? Is it legal for ebuilds to call has_version and friends
after the ebuild process has terminated? Discuss.
Do
On Sun, 30 Dec 2007 20:11:16 -0800
Alec Warner [EMAIL PROTECTED] wrote:
On 12/30/07, Ciaran McCreesh [EMAIL PROTECTED] wrote:
Is it legal for ebuilds to call has_version and friends in
parallel? Is it legal for ebuilds to call has_version and friends
after the ebuild process has terminated?
On Sat, 22 Dec 2007 16:43:10 +0100
Piotr Jaroszyński [EMAIL PROTECTED] wrote:
Hello,
I have updated the GLEP, hopefully it is less confusing now and hence the
discussion
will be more technical.
Still doesn't address my concerns, namely:
- silently expands the scope of EAPI beyond ebuild
On Mon, 31 Dec 2007 15:33:51 +0100
Marius Mauch [EMAIL PROTECTED] wrote:
- silently expands the scope of EAPI beyond ebuild contents (which is
a blocker for me)
That already happened with EAPI 1 and slot deps.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 20 Dec 2007 15:50:02 +0300
Peter Volkov [EMAIL PROTECTED] wrote:
This hack is just to solve portage problem which does not ignore .ebuild
files which does not follow pkg-ver.ebuild syntax and suggested solution
is not the only solution. Other possibilities are, which I like more:
1.
Is it legal for an eclass to check the EAPI version (presumably by using the
EAPI
variable) and perform some dependent behavior based on what it sees? I don't
see
any eclasses using EAPI for anything, so I'm curious.
--
[EMAIL PROTECTED] mailing list
On Fri, 28 Dec 2007 23:34:44 + (UTC)
Duncan [EMAIL PROTECTED] wrote:
I understand the ban on non-EAPI-0 features in in-tree profiles, since
users could be using old PMs, but it's fine using them in /etc/portage/*,
provided one has upgraded to an appropriately compatible PM, correct?
Yes
On Fri, 28 Dec 2007 12:03:12 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Thu, 27 Dec 2007 23:26:27 +0100
Luca Barbato [EMAIL PROTECTED] wrote:
Marius Mauch wrote:
Nope. EAPI (from my POV) defines the API that a package manager has
to export to an ebuild/eclass. That includes
On Mon, 31 Dec 2007 09:34:05 -0500 (EST)
Caleb Tennis [EMAIL PROTECTED] wrote:
Is it legal for an eclass to check the EAPI version (presumably by
using the EAPI variable) and perform some dependent behavior based on
what it sees? I don't see any eclasses using EAPI for anything, so
I'm
On Mon, 31 Dec 2007 15:46:06 +0100
Marius Mauch [EMAIL PROTECTED] wrote:
The issue is with comparison rules. For the current use case that's
not an issue as it's simply a superset, so we could just use the new
rules for everything. But if the rules are changed in an incompatible
way, which
Marius Mauch wrote:
On Sun, 30 Dec 2007 19:54:04 -0500
Mark Loeser [EMAIL PROTECTED] wrote:
Let me know if you like any of those ideas, or if they all suck (and if
they do, you better tell me why). I'm not sure which is the best way
forward, which is why I want everyone to contribute towards
On Monday 31 of December 2007 15:33:51 Marius Mauch wrote:
Still doesn't address my concerns, namely:
- silently expands the scope of EAPI beyond ebuild contents (which is a
blocker for me)
And what is the reason for not doing exactly that? Seems logical to me. And
btw. slot deps added in
On Dec 31, 2007 3:30 PM, Marius Mauch [EMAIL PROTECTED] wrote:
What benefit does use.xml have over use.desc?
[...]
No need to change the format of use.desc
Anything that would enable us to document with more than a few words,
which is what we're practically limited to with the current format of
Alec Warner [EMAIL PROTECTED] said:
One of the GLEP's primary goals is to provide a global use flag
definition and over-ride
it with a local definition. How does putting all flags in use.desc
and over-riding local flags in
use.local.desc not accomplish this?
It does, and maybe that's what
Doug Klima [EMAIL PROTECTED] said:
Marius Mauch wrote:
What benefit does use.xml have over use.desc?
My opinion is that we should use use.desc for a complete list of use
flags, including a generic description, allow a more verbose
description in metadata.xml and get rid of the stupid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
brltty is one of our accessibility packages. It is a program that
drives a braille display which is one way a blind person can access the
computer.
The project's guidelines for linux distributions at
On Mon, 31 Dec 2007 15:09:33 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Mon, 31 Dec 2007 15:46:06 +0100
Marius Mauch [EMAIL PROTECTED] wrote:
The issue is with comparison rules. For the current use case that's
not an issue as it's simply a superset, so we could just use the new
On Mon, 31 Dec 2007 14:40:57 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Mon, 31 Dec 2007 15:33:51 +0100
Marius Mauch [EMAIL PROTECTED] wrote:
- silently expands the scope of EAPI beyond ebuild contents (which is
a blocker for me)
That already happened with EAPI 1 and slot deps.
On Mon, 31 Dec 2007 18:55:10 +0100
Denis Dupeyron [EMAIL PROTECTED] wrote:
On Dec 31, 2007 3:30 PM, Marius Mauch [EMAIL PROTECTED] wrote:
What benefit does use.xml have over use.desc?
[...]
No need to change the format of use.desc
Anything that would enable us to document with more than
21 matches
Mail list logo
