Hello,
The current dependency syntax:
[VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
suffers a few problems:
1. It is not really human-friendly.
People don't say things like:
I need newer than monkey-1.2.
They say instead:
I need monkey, newer than version 1.2.
2. With long packag
El vie, 21-09-2012 a las 21:01 +0200, Pacho Ramos escribió:
> El jue, 20-09-2012 a las 14:23 -0400, Ian Stakenvicius escribió:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > On 20/09/12 02:12 PM, Michael Mol wrote:
> > > On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos
> > > wrote:
>
> On Sat, 22 Sep 2012, Michał Górny wrote:
> A package name can't end up with something looking like version.
> Thus, if upstream names package:
> frobnicator-11
> We need to rename it in the tree, effectively losing the ability to
> follow upstream naming and introducing a bunch of unnec
On Sat, 22 Sep 2012 10:18:31 +0200
Ulrich Mueller wrote:
> > On Sat, 22 Sep 2012, Michał Górny wrote:
>
> > A package name can't end up with something looking like version.
>
> > Thus, if upstream names package:
>
> > frobnicator-11
>
> > We need to rename it in the tree, effectively lo
> On Sat, 22 Sep 2012, Michał Górny wrote:
>> What is currently not allowed are package names ending with a hyphen
>> followed by digits only (as in your above example). This seems to be
>> completely arbitrary, and we could remove this limitation, even with
>> existing dependency syntax.
> I
On Sep 22, 2012 10:58 AM, "Michał Górny" wrote:
>
> Hello,
>
> The current dependency syntax:
>
> [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
>
> suffers a few problems:
The syntax you are describing is used all over portage, not just
dependencies. Some examples are the /etc/portage/package
On 09/22/2012 09:55 AM, Michał Górny wrote:
> Hello,
>
> The current dependency syntax:
>
> [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
>
> suffers a few problems:
I like the current syntax.
lu
On 09/03/2012 10:54 PM, Maciej Mrozowski wrote:
> On Tuesday 28 of August 2012 02:15:40 hasufell wrote:
>> Is there a reason not to support static-libs in an ebuild if the package
>> supports it?
>>
>> It seems some developers don't care about this option. What's the gentoo
>> policy on this? Isn't
On Sat, 22 Sep 2012 09:55:08 +0200
Michał Górny wrote:
> The fore-mentioned problems could be solved through introducing a more
> natural dependency syntax:
>
> PACKAGE-NAME [[*WSP] VERSION-OP [*WSP] PACKAGE-VERSION]]
If we'd rather not break backwards compatibility and add in all kinds
of whi
On 09/21/2012 06:06 PM, Zac Medico wrote:
> On 09/20/2012 10:34 AM, Ambroz Bizjak wrote:
>> The question now is, how should this method for checking
>> --crosscompile be implemented? In particular, we have two options:
>>
>> - Environment variable. If so, how to call it? Possible names are
>> CROSS
On 09/22/2012 05:15 PM, Luca Barbato wrote:
> On 09/03/2012 10:54 PM, Maciej Mrozowski wrote:
>> On Tuesday 28 of August 2012 02:15:40 hasufell wrote:
>>> Is there a reason not to support static-libs in an ebuild if the package
>>> supports it?
>>>
>>> It seems some developers don't care about this
On Sat, 22 Sep 2012 17:12:04 +0200
Luca Barbato wrote:
> On 09/22/2012 09:55 AM, Michał Górny wrote:
> > Hello,
> >
> > The current dependency syntax:
> >
> > [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> >
> > suffers a few problems:
>
> I like the current syntax.
Does that invalidate
On 09/22/2012 05:25 PM, hasufell wrote:
> add_library(foostatic STATIC foo.cpp foo.h)
> set_target_properties(foostatic PROPERTIES OUTPUT_NAME foo)
> add_library(foo SHARED foo.cpp foo.h)
Looks a bit kludgy but should work well as a macro, willing to contact
upstream and/or ask cmake devs to incl
Yes, I think this is a good idea, it would allow the dependencies to
be expressed nicely as conditions.
But I'm not sure how this would be a USE flag. It should behave like
one during the build, but it would be best if it was not written into
the VDB as such, at least in a way that would be consid
On 09/22/2012 09:55 AM, Michał Górny wrote:
> Hello,
>
> The current dependency syntax:
>
> [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
>
> suffers a few problems:
I like the current one your proposal seems quite a problem for a large
deal of usecases.
> 1. It is not really human-friendl
On Sat, 22 Sep 2012 18:13:48 +0200
Luca Barbato wrote:
> On 09/22/2012 09:55 AM, Michał Górny wrote:
> > Hello,
> >
> > The current dependency syntax:
> >
> > [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> >
> > suffers a few problems:
>
> I like the current one your proposal seems quite
On 09/22/2012 09:08 AM, Ambroz Bizjak wrote:
> Yes, I think this is a good idea, it would allow the dependencies to
> be expressed nicely as conditions.
>
> But I'm not sure how this would be a USE flag. It should behave like
> one during the build, but it would be best if it was not written into
On Sat, 22 Sep 2012 12:07:38 +0300
Alex Alexander wrote:
> On Sep 22, 2012 10:58 AM, "Michał Górny" wrote:
> >
> > Hello,
> >
> > The current dependency syntax:
> >
> > [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> >
> > suffers a few problems:
>
> The syntax you are describing is used al
On 23 September 2012 00:13, Luca Barbato wrote:
> Please try not fix/break what is not broken.
+1
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
On 22/09/2012 09:35, Ben de Groot wrote:
>> > Please try not fix/break what is not broken.
> +1
Same here.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Zac, I think you misunderstood me here. Crosscompile-only HDEPEND is
definitely necessary, I've seen many packages need this. But what I'm
suggesting is that we also, and maybe only, need "ROOT != /" - only
HDEPEND dependencies. This means that the dependency would only be
required if the package i
On 09/22/2012 09:48 AM, Ambroz Bizjak wrote:
> Zac, I think you misunderstood me here. Crosscompile-only HDEPEND is
> definitely necessary, I've seen many packages need this. But what I'm
> suggesting is that we also, and maybe only, need "ROOT != /" - only
> HDEPEND dependencies. This means that t
On Sat, 2012-09-22 at 09:55 +0200, Michał Górny wrote:
> Hello,
>
> The current dependency syntax:
>
> [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
>
> suffers a few problems:
>
>
> 1. It is not really human-friendly.
>
> People don't say things like:
>
> I need newer than monkey-1.2.
On Sep 22, 2012 7:38 PM, "Michał Górny" wrote:
>
> emerge 'foo >= 1.1' 'bar < 1.0'?
> emerge foo '>=' 1.1 bar '<' 1.0?
How is the above easier to read than
emerge >=foo-1.1
Yes, sysroot is much better, thanks :)
So, does anyone have any objections to just having a sysroot condition
and no --crosscompile or FEATURES=crosscompile?
Essentially, there's still tc-is-cross-compiler, if you want the real
cross-compile semantic, and sysroot conditional dependencies cover an
On Sat, 22 Sep 2012 10:05:41 -0700
Brian Dolbec wrote:
> On Sat, 2012-09-22 at 09:55 +0200, Michał Górny wrote:
> > Hello,
> >
> > The current dependency syntax:
> >
> > [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> >
> > suffers a few problems:
> >
> >
> > 1. It is not really human-fr
On Sat, 22 Sep 2012 20:11:48 +0300
Alex Alexander wrote:
> On Sep 22, 2012 7:38 PM, "Michał Górny" wrote:
> >
> > emerge 'foo >= 1.1' 'bar < 1.0'?
> > emerge foo '>=' 1.1 bar '<' 1.0?
>
> How is the above easier to read than
>
> emerge >=foo-1.1 =foo-1.1' ' I think your example is working agai
On Sep 22, 2012 8:25 PM, "Michał Górny" wrote:
>
> On Sat, 22 Sep 2012 20:11:48 +0300
> Alex Alexander wrote:
>
> > On Sep 22, 2012 7:38 PM, "Michał Górny" wrote:
> > >
> > > emerge 'foo >= 1.1' 'bar < 1.0'?
> > > emerge foo '>=' 1.1 bar '<' 1.0?
> >
> > How is the above easier to read than
> >
On 09/22/2012 10:14 AM, Ambroz Bizjak wrote:
> Yes, sysroot is much better, thanks :)
>
> So, does anyone have any objections to just having a sysroot condition
> and no --crosscompile or FEATURES=crosscompile?
>
> Essentially, there's still tc-is-cross-compiler, if you want the real
> cross-comp
oops, didn't reply to the list. re-sending
On Sat, 2012-09-22 at 19:19 +0200, Michał Górny wrote:
> On Sat, 22 Sep 2012 10:05:41 -0700
> So, I think you just don't like it and are inventing disadvantages
> without even caring enough to consider them before writing.
>
Oh, I considered it for th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/22/2012 09:55 AM, Michał Górny wrote:
> Hello,
>
> The current dependency syntax:
>
> [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
>
> suffers a few problems:
>
>
> 1. It is not really human-friendly.
>
> People don't say things like:
>
Hello
This comes from:
http://www.gossamer-threads.com/lists/gentoo/dev/260536
In that one, we try to use the following:
has vala ${IUSE//+/} && ! use vala && return 0
as already done in many eclasses/ebuilds (some of them as widely used as
xorg-2 or cmake eclasses) for years. The problem is th
No.
Alex Alexander wrote:
>On Sep 22, 2012 8:25 PM, "Michał Górny" wrote:
>>
>> On Sat, 22 Sep 2012 20:11:48 +0300
>> Alex Alexander wrote:
>>
>> > On Sep 22, 2012 7:38 PM, "Michał Górny" wrote:
>> > >
>> > > emerge 'foo >= 1.1' 'bar < 1.0'?
>> > > emerge foo '>=' 1.1 bar '<' 1.0?
>> >
>> > How is
On Sat, 22 Sep 2012 21:41:24 +0200
Pacho Ramos wrote:
> Hello
>
> This comes from:
> http://www.gossamer-threads.com/lists/gentoo/dev/260536
>
> In that one, we try to use the following:
> has vala ${IUSE//+/} && ! use vala && return 0
Just please stop repeating the random broken snippet and
It is a simple eclass using autotools out-of-source builds to build
packages for multiple ABIs when multilib is supported.
Use case: xorg packages, ask Matt.
---
gx86/eclass/autotools-multilib.eclass | 72 +++
1 file changed, 72 insertions(+)
create mode 100644 gx
"Michał Górny" wrote:
>It is a simple eclass using autotools out-of-source builds to build
>packages for multiple ABIs when multilib is supported.
>
>Use case: xorg packages, ask Matt.
>---
>gx86/eclass/autotools-multilib.eclass | 72
>+++
> 1 file changed, 72 inser
On Sat, 22 Sep 2012 23:44:43 +0200
Luca Barbato wrote:
> "Michał Górny" wrote:
>
> >It is a simple eclass using autotools out-of-source builds to build
> >packages for multiple ABIs when multilib is supported.
> >
> >Use case: xorg packages, ask Matt.
> >---
> >gx86/eclass/autotools-multilib.ec
On Sat, 22 Sep 2012 23:24:46 +0200
Michał Górny wrote:
> It is a simple eclass using autotools out-of-source builds to build
> packages for multiple ABIs when multilib is supported.
>
to some extent, can't you do the same by unpacking twice to different
$S and calling src_prepare/compile/install
On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny wrote:
> It is a simple eclass using autotools out-of-source builds to build
> packages for multiple ABIs when multilib is supported.
Thanks a lot, Michał! This looks good to me.
> Use case: xorg packages, ask Matt.
So the idea is that users want up
On 22/09/2012 18:54, Matt Turner wrote:
> I'd like to add multilib USE flags to Mesa and thus its dependencies.
> I realized that almost everything in x11-libs/ could be converted very
> easily, which would allow us to get rid of emul-linux-x86-xlibs in
> addition to emul-linux-x86-opengl.
If that
On Sat, Sep 22, 2012 at 6:59 PM, Diego Elio Pettenò
wrote:
> On 22/09/2012 18:54, Matt Turner wrote:
>> I'd like to add multilib USE flags to Mesa and thus its dependencies.
>> I realized that almost everything in x11-libs/ could be converted very
>> easily, which would allow us to get rid of emul
42 matches
Mail list logo
