Markus Meier <[EMAIL PROTECTED]>:
No, to the following (others already gave reasons):
> server12
> custom-cflags 7
> multislot 6
> editor5
Is ambigious, too.
[-] editor (games-arcade/bomns):
enables building
On Thu, 2007-12-20 at 19:57 +0100, Markus Meier wrote:
> Potential candidates (flag-name, count):
> xemacs5
This count will very likely go up in the future as we enable more
support for packages similar to the level of support for emacs. +1 on
making this a global USE flag.
On Fri, 21 Dec 2007 07:24:26 +0100
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Since seems that enough people are against this glep and many are
> undecided I started polling around for alternatives...
But there has yet to be a correct technical objection, nor a correct
alternative proposed, nor a d
Ciaran McCreesh wrote:
>> Near as I can tell, it's only the Paludis folks that are interested
>> in pushing this GLEP through.
>
> Have you tried asking the Portage developer?
>
yes, and I'm waiting for others' opinions too ^^;
Since seems that enough people are against this glep and many are
u
On Thu, 20 Dec 2007 20:46:35 -0800
Josh Saddler <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 21 Dec 2007 03:17:12 +0100
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >> Putting a tag in the file name or at the to of the file as comment
> >> (maybe using a #! line) is the same ...
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 03:17:12 +0100
> Luca Barbato <[EMAIL PROTECTED]> wrote:
>> Putting a tag in the file name or at the to of the file as comment
>> (maybe using a #! line) is the same ...
> * It's a format restriction. Some formats have to start with something
> that's n
On Fri, 21 Dec 2007 12:27:31 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> But I am not sick of EAPI's. You see? I am sick of so *many* EAPI's.
What? All two of them that you need to know about, where the second
one is the first one with three new features?
--
Ciaran McCreesh
signature.asc
Descr
On Fri, 21 Dec 2007 12:20:31 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> It is not about whether it is agreed upon currently.
It is. That's the entire point of the whole discussion.
> As long as there is an agreement in any given point of time, it is OK.
> Such as, put your EAPI definition on the
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 12:03:25 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>> We can't take the risk of forking/splitting ourselves in exchange of
>> only a little features.
>
> EAPI introduces no risk of that. Quite the opposite -- it reduces it by
> making it less likely t
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:56:35 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>> By "all people", I mean all those who have participated in this
>> discussion. They shown their concern.
>> We should listen to what they said.
>
> Even when what they said was nonsense
No nonsen
On Fri, 21 Dec 2007 12:15:10 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> I think we should first decide on how EAPI works.
That was decided a long time ago.
> Just because we need a new feature, then we produce a new EAPI?
> I think that is not feasible, and will confuse developers.
Uh... Yes. I
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:51:03 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>> That's the problem about the agreement between PM and ebuild.
>>
>> If this is agreed upon
>>> import vim-spell using language="en"
>> You should be able to get it.
>>
>> If not, then blame the
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:23:08 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>
>> I really don't see the necessity to have so many EAPI's
>
> A new EAPI is needed for new features, so new EAPIs will be needed in
> the future. Equally, migrating the whole tree at once to newer
On Fri, 21 Dec 2007 12:03:25 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> We can't take the risk of forking/splitting ourselves in exchange of
> only a little features.
EAPI introduces no risk of that. Quite the opposite -- it reduces it by
making it less likely that people will get sick of the ina
On Fri, 21 Dec 2007 11:56:35 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> By "all people", I mean all those who have participated in this
> discussion. They shown their concern.
> We should listen to what they said.
Even when what they said was nonsense and the equivalent of running
around saying t
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:34:07 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>>> * We have to wait a year before we can use it.
>> Why rush on this thing?
>> If the EAPI's feature is not freezing, I think we should do nothing
>> but wait.
>
> There's no reason to make Gentoo g
On Fri, 21 Dec 2007 11:51:03 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> That's the problem about the agreement between PM and ebuild.
>
> If this is agreed upon
> > import vim-spell using language="en"
> You should be able to get it.
>
> If not, then blame the ebuild writer. There is no prob
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:38:43 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>> I am afraid if we want all people accept this GLEP wholeheartedly,
>> someone ought to be stand out and take this responsibility.
>
> No no, we want all the people who are qualified to discuss it t
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:26:06 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>>> And no, it's not worth writing them. If people have time to spend
>>> documenting ebuildy things, there are a lot more useful places to
>>> start.
>> It worths. It will influence our future.
>
> A
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 10:52:04 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>> Ciaran McCreesh wrote:
>>> On Fri, 21 Dec 2007 03:14:12 +0100
>>> Luca Barbato <[EMAIL PROTECTED]> wrote:
Ciaran McCreesh wrote:
> Ok. What's the EAPI for the following ebuild that's writte
On Fri, 21 Dec 2007 11:38:43 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> I am afraid if we want all people accept this GLEP wholeheartedly,
> someone ought to be stand out and take this responsibility.
No no, we want all the people who are qualified to discuss it to accept
it, and the rest to acce
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 10:49:04 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>
>> It should not appear as a black box, and effectively prevent normal
>> gentoo users and developers from contributing to decisions which may
>> have a great impact on their distro.
>
> The GLEP d
On Fri, 21 Dec 2007 11:34:07 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> > * We have to wait a year before we can use it.
>
> Why rush on this thing?
> If the EAPI's feature is not freezing, I think we should do nothing
> but wait.
There's no reason to make Gentoo go even longer without features.
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 11:09:44 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>> I see it differently.
>> Everyone participated in this discussion has shown their concerns
>> about their distro.
>> If someone don't understand, we should help them to understand, not
>> just exclu
On Fri, 21 Dec 2007 11:26:06 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> > There are none. If anyone really wants to know, they can read the
> > code for their package manager of choice (or better, all of them).
>
> Then I suggest stop this discussion and make a documentation first.
> Seriously.
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 03:17:12 +0100
> Luca Barbato <[EMAIL PROTECTED]> wrote:
>> Putting a tag in the file name or at the to of the file as comment
>> (maybe using a #! line) is the same ...
>
> Three problems:
>
> * We have to wait a year before we can use it.
Why rush o
On Fri, 21 Dec 2007 11:23:08 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> > Quite the opposite. EAPI's are designed to live happily together in
> > the same repository. A current example: most (or lots...) ebuilds in
> > the tree don't need EAPI="1" and it's pointless to migrate all of
> > them. We
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 03:46:00 +0100
> Luca Barbato <[EMAIL PROTECTED]> wrote:
>> Ciaran McCreesh wrote:
>>> People who know what they're talking about are more than welcome to
>>> contradict me. People who don't understand what's being discussed
>>> (which is most people in
Santiago M. Mola wrote:
> On Dec 20, 2007 8:01 PM, Zhang Le <[EMAIL PROTECTED]> wrote:
>> How many EAPI's do we have now?
>
> In Portage tree we have "0" (default) and "1". There are others in
> external projects, for example "prefix" (in Gentoo/Alt:Prefix) or
> "paludis-1" (used in paludis reposi
On Fri, 21 Dec 2007 11:09:44 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> no slang in one's words is just a minimum requirement of
> communication.
There was no slang. That was plain English.
> I see it differently.
> Everyone participated in this discussion has shown their concerns
> about their
On Fri, 21 Dec 2007 10:59:14 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> However, it is only 3 chars.
> ebuild-1 is way too long, which is what I think not elegant.
Why? This is Unix, not dos.
> And file extension like welcome.html.fr is quite self-explanatory.
> But an total outsider has no chan
Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 14:54:10 +0100
> "Denis Dupeyron" <[EMAIL PROTECTED]> wrote:
>> On Dec 20, 2007 12:12 PM, Ciaran McCreesh
>> <[EMAIL PROTECTED]> wrote:
>>> I'm guessing there're lots of people moaning because they think they
>>> understand filenames and can therefore co
On Fri, 21 Dec 2007 03:46:00 +0100
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > People who know what they're talking about are more than welcome to
> > contradict me. People who don't understand what's being discussed
> > (which is most people in this thread) need to learn t
On Fri, 21 Dec 2007 10:49:04 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> > Because the process is decidedly non-trivial, and anyone who hasn't
> > spent a considerable time studying it and understanding it isn't
> > going to be able to contribute anything useful anyway.
>
> But human beings are ab
On Fri, 21 Dec 2007 03:44:20 +0100
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 21 Dec 2007 03:14:12 +0100
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >> Ciaran McCreesh wrote:
> >>> Ok. What's the EAPI for the following ebuild that's written in an
> >>> EAPI that
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 02:52:16 +0800
> Zhang Le <[EMAIL PROTECTED]> wrote:
>> Exactly.
>> And this way is not elegant.
>> File name is used to uniquely identify a file in a system, not to
>> decide how the content of the file should be interpreted.
>> Never ever seen a file t
On Fri, 21 Dec 2007 10:52:04 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 21 Dec 2007 03:14:12 +0100
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >> Ciaran McCreesh wrote:
> >>> Ok. What's the EAPI for the following ebuild that's written in an
> >>> EAPI that hasn
On Fri, 21 Dec 2007 03:41:04 +0100
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 21 Dec 2007 03:17:12 +0100
> > Luca Barbato <[EMAIL PROTECTED]> wrote:
> >> Putting a tag in the file name or at the to of the file as comment
> >> (maybe using a #! line) is the same ...
Ciaran McCreesh wrote:
> People who know what they're talking about are more than welcome to
> contradict me. People who don't understand what's being discussed
> (which is most people in this thread) need to learn to stop wasting
> people's time.
Point the documents that could help people getting
Ciaran McCreesh wrote:
> On Fri, 21 Dec 2007 03:17:12 +0100
> Luca Barbato <[EMAIL PROTECTED]> wrote:
>> Putting a tag in the file name or at the to of the file as comment
>> (maybe using a #! line) is the same ...
>
> Three problems:
>
> * We have to wait a year before we can use it.
We have to
On Fri, 21 Dec 2007 03:17:12 +0100
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Putting a tag in the file name or at the to of the file as comment
> (maybe using a #! line) is the same ...
Three problems:
* We have to wait a year before we can use it.
* It's a format restriction. Some formats have
On Fri, 21 Dec 2007 03:14:12 +0100
Luca Barbato <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Ok. What's the EAPI for the following ebuild that's written in an
> > EAPI that hasn't been published yet? And how would I extract it?
> >
> > # Copyright blah blah
> >
> > import vim-spell usi
Ciaran McCreesh wrote:
> No. Issues like this benefit from *well informed* diverse viewpoints.
> They don't benefit from people running around going "waah! waah!
> doesn't look nice! add format restrictions!" without understanding why
> it's necessary.
Putting a tag in the file name or at the to o
Ciaran McCreesh wrote:
> Ok. What's the EAPI for the following ebuild that's written in an EAPI
> that hasn't been published yet? And how would I extract it?
>
> # Copyright blah blah
>
> import vim-spell using language="en"
If isn't published it doesn't exist in the main tree...
lu
--
Luca
Ciaran McCreesh wrote:
custom-cflags 7
This one shouldn't be a use flag at all. Pushing it global will just
encourage even more people to use it.
+1
--
looks like christmas at fifty-five degrees
this latitude weakens
On Thu, 20 Dec 2007 19:57:12 +0100
Markus Meier <[EMAIL PROTECTED]> wrote:
> server12
See previous discussions on why this can't be global (essentially, it
has different meanings for everything).
> custom-cflags 7
This one shouldn't be a use flag at all. P
On Thu, 20 Dec 2007 14:54:10 +0100
"Denis Dupeyron" <[EMAIL PROTECTED]> wrote:
> On Dec 20, 2007 12:12 PM, Ciaran McCreesh
> <[EMAIL PROTECTED]> wrote:
> > I'm guessing there're lots of people moaning because they think they
> > understand filenames and can therefore comment. Unfortunately, most
>
On Thu, 20 Dec 2007 14:33:25 -0700
Joe Peterson <[EMAIL PROTECTED]> wrote:
> P.S. I just joined Gentoo this year, and it is disheartening to see
> the nastiness that some people are resorting to on this list. I've
> never seen so much anger and biting remarks in a project, and I can
> imagine it
On Fri, 21 Dec 2007 02:52:16 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> Exactly.
> And this way is not elegant.
> File name is used to uniquely identify a file in a system, not to
> decide how the content of the file should be interpreted.
> Never ever seen a file type extension with a version num
On Thu, 20 Dec 2007 08:56:01 -0500
Richard Freeman <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > Because a) a future EAPI might want to change EAPI into a function
> > rather than a variable,
>
> Why? It couldn't be dynamic - not if you're going to put it in the
> filename as well. An
On Fri, 21 Dec 2007 02:45:48 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > And again, you show that you don't understand what's going on. EAPI
> > is only specified once except where developers screw up. The GLEP
> > merely moves the EAPI to being set *before* the metadata
On Thu, 20 Dec 2007 12:48:31 +
Steve Long <[EMAIL PROTECTED]> wrote:
> Point is that your filename format restricts it in exactly the same
> manner. So let's just stick with the use cases which /that/ supports,
> which can more easily be supported with the original design and the
> simple restr
On Thu, 20 Dec 2007 16:57:54 +0100
Michael Haubenwallner <[EMAIL PROTECTED]> wrote:
> What if we do not start with "EAPI=1" variable, but "eapi 1" function
> immediately ?
Uh. Then we're back to the zillion months wait before people can
use anything.
> *) Given it is the first bash-command in
On Fri, 21 Dec 2007 02:27:27 +0800
Zhang Le <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > You need to understand the metadata generation process to
> > understand why the package manger has to assume a particular EAPI
> > when generating the metadata.
>
> There are many people watching
On Thursday, 20. December 2007 21:27:03 Markus Ullmann wrote:
> Erm no, PMS isn't officially until council made a decision on it (and
> I'm not aware of one yet).
> Currently "official" EAPIs are 0 and 1.
And EAPI-1 is defined where? :)
--
Best regards, Wulf
signature.asc
Description: This is
Santiago M. Mola wrote:
> These are potentially ambiguos.
Could you please elaborate a bit about the raw one?
Cheers,
-jkt
--
cd /local/pub && more beer > /dev/mouth
signature.asc
Description: OpenPGP digital signature
Thomas Pani wrote:
> My concern is technical: Filenames are for identifying files uniquely.
> An ebuild is uniquely identified by /-, so that's what it's
> filename should be. Adding anything else to the filename will only
> clutter the tree and lead to additional inconsitencies. Yes, you can
> che
Santiago M. Mola wrote:
> On Dec 20, 2007 8:01 PM, Zhang Le <[EMAIL PROTECTED]> wrote:
>> Where is the detailed definition of those EAPI's?
>
> "0", "1" and any further official EAPI are defined in PMS. There's a
> svn repository at http://svn.repogirl.net/pms
Erm no, PMS isn't officially until c
On 16:33 Thu 20 Dec , Caleb Tennis (caleb) wrote:
> Revision ChangesPath
> 1.1 x11-libs/qt-opengl/qt-opengl-4.4.0_rc1.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-libs/qt-opengl/qt-opengl-4.4.0_rc1.ebuild?rev=1.1&view=markup
> plain:
> http://
On 11:26 Thu 20 Dec , Bo Ørsted Andresen wrote:
> On Thursday 20 December 2007 11:09:44 Donnie Berkholz wrote:
> > > > Looking at my kernel config, ext3 and reiser explicitly support
> > > > xattrs, and I see jfs and xfs have acls and security labels,
> > > > which might be usable.
> [...]
>
On Dec 20, 2007 8:01 PM, Zhang Le <[EMAIL PROTECTED]> wrote:
>
> How many EAPI's do we have now?
In Portage tree we have "0" (default) and "1". There are others in
external projects, for example "prefix" (in Gentoo/Alt:Prefix) or
"paludis-1" (used in paludis repositories).
> Where is the detailed
Petteri Räty wrote:
> Donnie Berkholz kirjoitti:
>> Unportable to filesystems that don't support extended attributes isn't
>> very interesting to me, unless they're common. Out of curiosity, do you
>> know which ones that would be? Looking at my kernel config, ext3 and
>> reiser explicitly suppo
On Dec 20, 2007 7:57 PM, Markus Meier <[EMAIL PROTECTED]> wrote:
>
> raw: Add support for raw image formats
> keyring: Enable gnome-keyring support for storing passwords
>
These are potentially ambiguos.
I have no objections for the others.
--
Santiago M. Mola
Jabber ID: [EMAIL PROTECTED]
--
[
Luca Barbato wrote:
> Before spending even more time on it, could we try to come up with a
> definition of what eapi is, which problem is trying to solve and put
> that somewhere that isn't a long thread or an handful of threads
> scattered across mailing lists.
I think we also need to know:
How m
Potential candidates (flag-name, count):
server12
subversion10
latex 9
suid 8
atm 7
zeroconf 7
logrotate 7
gimp 7
Jim Ramsay wrote:
> Luca Barbato <[EMAIL PROTECTED]> wrote:
>> How would it be different than having EAPI="string" put in a defined
>> position of the file?
>
> It's not - It is just defining that position to be in the name of the
> file instead of the contents :)
Exactly.
And this way is not ele
Ciaran McCreesh wrote:
> And again, you show that you don't understand what's going on. EAPI is
> only specified once except where developers screw up. The GLEP merely
> moves the EAPI to being set *before* the metadata is generated, which
> removes all the restrictions that having EAPI as part of
Ciaran McCreesh wrote:
> I'm guessing there're lots of people moaning because they think they
> understand filenames and can therefore comment. Unfortunately, most of
> those people don't understand the metadata generation process, and
> therefore can't comment usefully...
So please make those peo
Ciaran McCreesh wrote:
>
> You need to understand the metadata generation process to understand why
> the package manger has to assume a particular EAPI when generating the
> metadata.
There are many people watching this thread all over the world I think.
Not all of them understand the process.
Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 09:43:59 + (UTC)
> Duncan <[EMAIL PROTECTED]> wrote:
>>> Because a) a future EAPI might want to change EAPI into a function
>>> rather than a variable, b) there are a zillion ways of setting a
>>> variable in bash and people already use all of them a
Luca Barbato wrote:
> Rémi Cardona wrote:
>
>> I'll speak up then :)
>>
>> What I _really_ would like to see ASAP :
>>
>> 1) Dropping digest-* files for real (ie, not even having them on the
>> master rsync server and CVS)
>>
Slated for after 2007.1 is released.
>> 2) Slotted deps (I had t
Rémi Cardona wrote:
> I'll speak up then :)
>
> What I _really_ would like to see ASAP :
>
> 1) Dropping digest-* files for real (ie, not even having them on the
> master rsync server and CVS)
>
> 2) Slotted deps (I had the feeling we were really close to having this a
> while back, and then rad
Wulf C. Krueger wrote:
>> I DO understand.
>
> You don't. The complete paragraph of yours shows you don't.
>
Interesting, because my statement is the same (in meaning) that Ciaran
made two days ago. He stated it was "[...] another option. It's
considered less ideal [...]" ([1], in case you want t
Luca Barbato a écrit :
> Wulf C. Krueger wrote:
>> a> "So we can make use of this feature in about a year?"
>> b> "Yeah."
>>
>> Are we Debian now? A new feature gets implemented (obviously because we
>> *need* it) and we can make use of it in a *year*?
>
> What do we need so desperately?
>
>>> So
On Thu, 2007-12-20 at 14:08 +0100, Thomas de Grenier de Latour wrote:
Seems that there is a chain of different metadata levels:
1) The parser/interpreter/compiler/whatever to grok the ebuild.
2) *How* to extract the EAPI value from the ebuild(-filename), using 1)
3) The *value* of EAPI for that
Wulf C. Krueger wrote:
> a> "So we can make use of this feature in about a year?"
> b> "Yeah."
>
> Are we Debian now? A new feature gets implemented (obviously because we
> *need* it) and we can make use of it in a *year*?
What do we need so desperately?
>
>> So either choose the one that's acc
On Thu, 2007-12-20 at 09:37 -0500, Caleb Tennis wrote:
> > How about splitting qmake out to help with the WebKitGtk stuff, so we
> > don't have to dep on qt?
>
> In theory it can be done very easily, because qmake doesn't rely on any Qt
> libraries. However, it DOES rely on all sorts of .prf and
> How about splitting qmake out to help with the WebKitGtk stuff, so we
> don't have to dep on qt?
In theory it can be done very easily, because qmake doesn't rely on any Qt
libraries. However, it DOES rely on all sorts of .prf and configure time option
files that are installed to the file system
> Great news. Why don't you split everything, though? In qt-4.3.0-r2, I
> see Core, Gui, Network, OpenGL, Sql, Script, Svg, Xml, Designer,
> UiTools, Assistant, 3Support, Test and DBus and can certainly imagine
> that at least putting the Gui out would make sense for console-based Qt
> applications
On Thu, 2007-12-20 at 09:05 -0500, Caleb Tennis wrote:
> Just a quick update on the happens in the x11-libs/qt world, as I'm
> introducing some
> changes that will probably affect people in the not-to-distant future.
>
> Since Qt is starting to get rather, ahem, big, I've decided that with the
>
Caleb Tennis wrote:
> Since Qt is starting to get rather, ahem, big, I've decided that with the
> introduction of version 4.4 it's a good time to try and split it down into
> more
> manageable chunks. I'm introducing a few new packages that are designed to
> break
> out some of the major pieces
Ciaran McCreesh wrote:
> Because that would be introducing a new, non-extensible, inflexible
> requirement upon the content of ebuilds, and the goal of EAPI is to
> avoid doing exactly that.
>
If you're putting all this metadata in the filename, I'm not sure how
you can distinguish between the fi
Just a quick update on the happens in the x11-libs/qt world, as I'm introducing
some
changes that will probably affect people in the not-to-distant future.
Since Qt is starting to get rather, ahem, big, I've decided that with the
introduction of version 4.4 it's a good time to try and split it do
Ciaran McCreesh wrote:
> Because a) a future EAPI might want to change EAPI into a function
> rather than a variable,
Why? It couldn't be dynamic - not if you're going to put it in the
filename as well. And why have it in two places? If you are going to
put the EAPI in the filename, why put it
On Dec 20, 2007 12:12 PM, Ciaran McCreesh
<[EMAIL PROTECTED]> wrote:
> I'm guessing there're lots of people moaning because they think they
> understand filenames and can therefore comment. Unfortunately, most of
> those people don't understand the metadata generation process, and
> therefore can't
Donnie Berkholz wrote:
> Here's some other ideas for how to express EAPI. What if we:
If this idea of eapi is the best. I'm doubtful it is.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
[EMAIL PROTECTED] mailing list
On Thu, Dec 20, 2007 at 02:12:24PM +0100, Bo Ørsted Andresen wrote:
> On Thursday 20 December 2007 13:48:31 Steve Long wrote:
> > >> (optimising early here seems silly tbh, given that paludis now
> > >> requires ruby.)
> > >
> > > Eh? Now what're you on about?
> >
> > http://bugs.gentoo.org/show_bu
On Thursday 20 December 2007 13:48:31 Steve Long wrote:
> >> (optimising early here seems silly tbh, given that paludis now
> >> requires ruby.)
> >
> > Eh? Now what're you on about?
>
> http://bugs.gentoo.org/show_bug.cgi?id=198864
So here you're showing that you don't know what a USE flag is?
-
On 2007/12/20, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> Uh, it works in both those cases. The package manager will simply not
> see the ebuild at all.
>
> Which is pretty much the point...
Yes, because a change in the way EAPI is read implies a change in the
files naming rule, so that the PM
On Dec 20, 2007 12:48 PM, Steve Long <[EMAIL PROTECTED]> wrote:
> Ciaran McCreesh wrote:
> > On Thu, 20 Dec 2007 00:07:35 +
> > Steve Long <[EMAIL PROTECTED]> wrote:
> >> (optimising early here seems silly tbh, given that paludis now
> >> requires ruby.)
> >
> > Eh? Now what're you on about?
>
I DO understand.
You don't. The complete paragraph of yours shows you don't.
But you're totally ignoring my point. So once again: You're trying to
*SET* a standard here. There are lots of people telling you that they're
not happy with the proposal to change the ebuild filename suffix.
Yes, i
While it's may be a good idea to set EAPI inside filename and if we ever
decide on this, consider different implementation.
I really dislike idea of EAPI-suffixed extensions. It's easier for me
(and I think for others too) to differentiate ebuilds between other
files in directory when ebuild files
Extended attributes can be turned off during compile time for each
filesystem you mentioned.
If you turn off features you need, things break. There's nothing new
about that. If you disable ext3 support in your kernel, you can't mount
an ext3 partition and you'll get an error during boot about not
Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 00:07:35 +
> Steve Long <[EMAIL PROTECTED]> wrote:
>> Do you think a generated EAPI is a good idea? I'm curious as to
>> how that would be reflected in the filename (as well as your reasons
>> ofc.)
>
> I'm suggesting that if EAPI is a variable, the
On Thu, 20 Dec 2007 12:06:59 +0100
Thomas Pani <[EMAIL PROTECTED]> wrote:
> But you're totally ignoring my point. So once again: You're trying to
> *SET* a standard here. There are lots of people telling you that
> they're not happy with the proposal to change the ebuild filename
> suffix. There se
Ciaran McCreesh wrote:
> On Thu, 20 Dec 2007 11:37:01 +0100
> Thomas Pani <[EMAIL PROTECTED]> wrote:
>> As cat/pkg-ver ultimately is ONE file in the filesystem, there's no
>> reason to put any information about the EAPI in the filename.
>
> Sure there is. It's the sanest place to put it such that
On Thu, 20 Dec 2007 11:37:01 +0100
Thomas Pani <[EMAIL PROTECTED]> wrote:
> As cat/pkg-ver ultimately is ONE file in the filesystem, there's no
> reason to put any information about the EAPI in the filename.
Sure there is. It's the sanest place to put it such that it's available
when it's needed -
Here's why I think you can't -- or at least shouldn't -- put EAPI into
the filename.
>From your EAPI definition:
> A cat/pkg-ver has exactly one EAPI. That EAPI belongs to the
> cat/pkg-ver as a whole, and is static across that cat/pkg-ver.
It's clearly NOT the purpose of a filename to describe h
Donnie Berkholz wrote:
> If you turn off features you need, things break. There's nothing new
> about that. If you disable ext3 support in your kernel, you can't mount
> an ext3 partition and you'll get an error during boot about not finding
> the root.
I see your point, but extended attributes
Hello all,
I have a new version of the eclass ready, with much of the remarks
addressed. It now goes by the name java-osgi and in the new form,
should be ready to enter the tree.
I fixed the performance problem I mentionned earlier, cleaned up the
eclass API, and simplified the code almost everyw
1 - 100 of 115 matches
Mail list logo
