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 de
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.
> >
>
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
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 e
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:
>
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?
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 i
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, whic
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 E
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
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
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 stupi
-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
http://www.mielke.cc/brltty/guidelines.html
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
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 sl
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 wi
21 matches
Mail list logo
