On Dec 20, 2007 1:38 AM, Donnie Berkholz [EMAIL PROTECTED] wrote:
Here's some other ideas for how to express EAPI. What if we:
[..]
Stuck ranges into metadata.xml for which EAPIs applied?
This is the easiest and most reasonable solution I've heard so far.
Denis.
--
[EMAIL PROTECTED] mailing
2007/12/18, Joe Peterson [EMAIL PROTECTED]:
Santiago M. Mola wrote:
One example was mentioned in this thread before: You cannot use
find -name '*.ebuild' anymore.
So people could use a bit more elaborated expression to find them.
Things like this shouldn't be a reason for not applying
On Wed, 19 Dec 2007 16:38:01 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
Here's some other ideas for how to express EAPI. What if we:
Used EAPI-named subdirectories instead of tagging it into the
filename?
Performance hit, and otherwise equivalent to using suffixes.
Used (and required)
On Thu, Dec 20, 2007 at 12:07:35AM +, Steve Long wrote:
Since only declaring it the once /seems/ ok with you, what on Earth is so
hard about extracting it? I'm sure ruby has sufficient text processing
capability if the C++ is a bit much for you; I remember there was that
long-term bug in
On 08:29 Thu 20 Dec , Ciaran McCreesh wrote:
On Wed, 19 Dec 2007 16:38:01 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
Here's some other ideas for how to express EAPI. What if we:
Used EAPI-named subdirectories instead of tagging it into the
filename?
Performance hit, and
Donnie Berkholz kirjoitti:
On 08:29 Thu 20 Dec , Ciaran McCreesh wrote:
On Wed, 19 Dec 2007 16:38:01 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
Here's some other ideas for how to express EAPI. What if we:
Used EAPI-named subdirectories instead of tagging it into the
filename?
Donnie Berkholz kirjoitti:
Icky.
chmod 0755 ${D}/usr/bin/${WRAPPERNAME}
chmod 0755 ${D}/usr/bin/${WRAPPERNAME}uri
fperms?
make_desktop_entry ${WRAPPERNAME} ${APPNAME} ${APPNAME}.png
System;Utility;Core;ROX
Thought I saw something about desktop entries dropping the
Fernando J. Pereda [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Wed, 19 Dec 2007
17:50:19 +0100:
On Wed, Dec 19, 2007 at 11:03:54AM -0500, Jim Ramsay wrote:
The sense I've gotten from this discussion so far is that if you want
features from two EAPIs you know *can* be
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.
Extended attributes can be turned off during compile time for each
filesystem you mentioned. NFSv3 doesn't support them
Ciaran McCreesh [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on Thu, 20 Dec
2007 03:54:00 +:
On Wed, 19 Dec 2007 20:28:55 -0500
Richard Freeman [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Wed, 19 Dec 2007 18:59:47 -0500
Richard Freeman [EMAIL PROTECTED] wrote:
On Thu, 20 Dec 2007 01:19:46 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
On 08:29 Thu 20 Dec , Ciaran McCreesh wrote:
On Wed, 19 Dec 2007 16:38:01 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:
Here's some other ideas for how to express EAPI. What if we:
Used EAPI-named
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 and c)
introducing new weird
On 10:43 Thu 20 Dec , Jan Kundrát wrote:
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.
Extended attributes can be turned off during compile time for each
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.
[...]
The idea of the sqlite-based fallback is what's interesting here.
I
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
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
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 how
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 --
Hi,
I'm planning to projectify very soon the TeX herd by adding a tex
subdirectory in gentoo/xml/htdocs/proj/en (like other languages
already have); This will be very minimalistic at first but will allow me
to put some documentation resources there (like the TeX Live migration
how-to), and also
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 it's
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 seem to
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, there are use
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
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
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,
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?
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 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?
--
Bo
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_bug.cgi?id=198864
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 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
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
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
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 into
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
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.
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.
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
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 accepted by the
On Thu, 2007-12-20 at 14:08 +0100, Thomas de Grenier de Latour wrote:
snip
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
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 either choose the one
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 to look
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 radio
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 the feeling we
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 and c)
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.
And
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 people
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 the
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 elegant.
File
Potential candidates (flag-name, count):
server12
subversion10
latex 9
suid 8
atm 7
zeroconf 7
logrotate 7
gimp 7
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 many
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]
--
[EMAIL
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 support
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 definition
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.
[...]
The idea of
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.1view=markup
plain:
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 council made
Thomas Pani wrote:
My concern is technical: Filenames are for identifying files uniquely.
An ebuild is uniquely identified by cat/pn-pv, 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
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
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 a
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 this
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 the
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
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 is
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. And why
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 number.
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 keeps
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
of those
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.
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
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:
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 of the
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 using language=en
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 to
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 wait till
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 an
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 ...
Three
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't been published
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 type extension
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 hasn't been
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 able to
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 to stop
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 comment.
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 chance to
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
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 repositories).
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 on this
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 exclude them from
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 doesn't have
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 accept
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 written in an
EAPI that
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.
And bringing
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 to accept
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 that
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 EAPIs is
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 ebuild writer. There is
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. It's
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 that people
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
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 not #!.
1 - 100 of 105 matches
Mail list logo
