Nirbheek Chauhan posted
8b4c83ad0905152258i61b0e8ebh869f323519b19...@mail.gmail.com, excerpted
below, on Sat, 16 May 2009 11:28:57 +0530:
> Why is it that this thread has 500 replies,
500? Try 34 posts in the fallacies of glep55 thread, total, including
OP, on that thread (not this one, no re
On Sat, May 16, 2009 at 12:33 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> Why is it that this thread has 500 replies,
>
> 500? Try 34 posts in the fallacies of glep55 thread, total, including
> OP, on that thread (not this one, no references header, single post as I
> read this). But who's counti
Hi!
On Fri, 15 May 2009, Ciaran McCreesh wrote:
> > eval `grep '^EAPI=' ebuildfile | head -n 1`
> >
> > will set EAPI in the current scope to EAPI in the ebuild, without
> > sourcing it, unless the issue with something like this would be its
> > use of grep and head, but these are both in the sy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Fri, 15 May 2009 14:43:29 -0500
> William Hubbs wrote:
>> On Thu, May 14, 2009 at 10:53:37PM +0100, Ciaran McCreesh wrote:
>>> It can't, because it doesn't know the EAPI until it's sourced the
>>> thing using bash. Using th
On Суббота 16 мая 2009 03:18:09 Luca Barbato wrote:
> Luca Barbato wrote:
> > Duncan wrote:
> >> Namespace pollution? QEMU_USER_TARGETS and QEMU_SOFTMMU_TARGETS, maybe?
> >
> > Right, anyway either one or two vars, anybody has a strong feeling
> > towards one of them or against any of them?
>
> QEM
On Thu, May 14, 2009 at 05:06:11PM -0700, Robin H. Johnson wrote:
> libusb-1 is in the tree now.
>
> This means that you get to go and test all your apps that use it.
> There's a list further down of all packages and all ebuilds.
I've opened a tracking bug for the migration:
https://bugs.gentoo.o
On Saturday 16 May 2009 10:27:51 Marijn Schouten (hkBst) wrote:
> How is it possible to do these things encoded in the filename?
For the export example, it's just a matter of using a different bash syntax
from what the magic regex expects, which is completely irrelevant if it goes
in the filenam
David Leverton wrote:
> But the point isn't that we want to be able to do those things. The point is
> that if the EAPI is in the filename, it's blatantly obvious that it has to be
> static, but adding strange and unintuitive restrictions on which shell
> constructs can be used is, well, strang
Nirbheek Chauhan wrote:
> The statistics are irrelevant.
So why do you bring them up?
> This stuff does not need to be resolved, put to rest, approved,
> disapproved, or whatever! It needs to be kicked out till we can get
> *BASIC* stuff fixed.
I agree, but apparently council thinks it's worth t
Tobias Klausmann posted
20090516092710.ga3...@eric.schwarzvogel.de, excerpted below, on Sat, 16
May 2009 11:27:10 +0200:
> On Fri, 15 May 2009, Ciaran McCreesh wrote:
>> or:
>>
>> inherit versionator
>>
>> if version_is_at_least 2 ; then
>> EAPI="2"
>> else
>> EAP
On Sat, May 16, 2009 at 4:48 PM, Ben de Groot wrote:
> Nirbheek Chauhan wrote:
>> The statistics are irrelevant.
>
> So why do you bring them up?
>
That's the question you should ask Duncan. Not me. I provided
statistics to highlight and provide dramatic effect. People who prefer
to discuss them
Nirbheek Chauhan wrote:
On Sat, May 16, 2009 at 4:48 PM, Ben de Groot wrote:
Nirbheek Chauhan wrote:
The statistics are irrelevant.
So why do you bring them up?
That's the question you should ask Duncan. Not me. I provided
statistics to highlight and provide dramatic effect. People who pre
David Leverton posted
200905161059.53706.levert...@googlemail.com, excerpted below, on Sat, 16
May 2009 10:59:53 +0100:
> But the point isn't that we want to be able to do those things. The
> point is that if the EAPI is in the filename, it's blatantly obvious
> that it has to be static, but ad
# Gilles Dartiguelongue (15 May 2009)
# Masked for removal wrt bug #244128. Old, rotten and
# unused. Removal in 30 days.
gnome-base/libghttp
another one bites the dust.
(resent from my gentoo address)
--
Gilles Dartiguelongue
Gentoo
signature.asc
Description: Ceci est une partie de message
Nirbheek Chauhan posted
8b4c83ad0905160454h132e44fboecd75784934fe...@mail.gmail.com, excerpted
below, on Sat, 16 May 2009 17:24:57 +0530:
> That's the question you should ask Duncan. Not me. I provided statistics
> to highlight and provide dramatic effect.
Wow, the number of follow-ups generate
On Sat, 16 May 2009 11:27:10 +0200
Tobias Klausmann wrote:
> Change the spec, then.
If we change the spec, we can't do anything with the change until we're
absolutely sure that everyone's updated both their ebuilds and their
package manager for it.
> Actually, I personally would prefer taking it
On Sat, 16 May 2009 12:14:23 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> I mean, for the longest time, the main (among many) boosting claim
> seemed to be that the speed difference between in-file and
> in-filename made the former prohibitive in practice. Perhaps the
> benchmarks the counci
On Sat, 16 May 2009 11:28:57 +0530
Nirbheek Chauhan wrote:
> Why do we let utterly *useless* discussions eat into our precious
> developer time?
>
> Why is it that this thread has 500 replies
Because the way Gentoo works, any objection to a proposal, valid or not,
whether or not it's already bee
Ciaran McCreesh wrote:
> On Sat, 16 May 2009 11:27:10 +0200
> Tobias Klausmann wrote:
>> Change the spec, then.
>
> If we change the spec, we can't do anything with the change until we're
> absolutely sure that everyone's updated both their ebuilds and their
> package manager for it.
>
Isn't tha
On Sat, 16 May 2009 15:50:39 +0100
Steven J Long wrote:
> Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 11:27:10 +0200
> > Tobias Klausmann wrote:
> >> Change the spec, then.
> >
> > If we change the spec, we can't do anything with the change until
> > we're absolutely sure that everyone's upda
I'm planning to request the stabling of gentoo-sources-2.6.29 on 23rd
may, 1 week from now. We have no known regressions in the kernel.
Regressions in external packages in the stable tree are tracked in bug
#264722. Please fix these asap.
Daniel
Ciaran McCreesh wrote:
You've missed the point. The point is, the EAPI process can't avoid the
"huge wait before we can use it" for certain types of change that
would be extremely useful. GLEP 55 fixes this limitation, and it's the
*only* thing that fixes this limitation.
Except that if we had
On Sat, 16 May 2009 11:15:58 -0400
Richard Freeman wrote:
> Ciaran McCreesh wrote:
> > You've missed the point. The point is, the EAPI process can't avoid
> > the "huge wait before we can use it" for certain types of change
> > that would be extremely useful. GLEP 55 fixes this limitation, and
> >
Nirbheek Chauhan wrote:
Let's not blatantly ignore our REAL problems. We can no longer afford
to maintain the status-quo of pedantic masturbatory discussions on the
finer points of ebuild formats. We cannot AFFORD to look the other way
while the distro rots away.
What exactly is your proposal?
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 11:27:10 +0200
> Tobias Klausmann wrote:
> > Change the spec, then.
>
> If we change the spec, we can't do anything with the change until we're
> absolutely sure that everyone's updated both their ebuilds and their
> package
Ciaran McCreesh wrote:
Had we gone with any of the other proposals a year ago, we'd be waiting
a year every time a new change came along.
Only if that change prevented obtaining EAPI from wherever it was
placed. If you want to make the rule "EAPI=foo appears at the start of
a new line at th
On Sat, 16 May 2009 17:32:24 +0200
Tobias Klausmann wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 11:27:10 +0200
> > Tobias Klausmann wrote:
> > > Change the spec, then.
> >
> > If we change the spec, we can't do anything with the change until
> > we're absolutely
On Sat, 16 May 2009 11:34:14 -0400
Richard Freeman wrote:
> Ciaran McCreesh wrote:
> > Had we gone with any of the other proposals a year ago, we'd be
> > waiting a year every time a new change came along.
>
> Only if that change prevented obtaining EAPI from wherever it was
> placed.
...or if
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 17:32:24 +0200
> Tobias Klausmann wrote:
> > On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > On Sat, 16 May 2009 11:27:10 +0200
> > > Tobias Klausmann wrote:
> > > > Change the spec, then.
> > >
> > > If we change the spec
Duncan wrote:
> Petteri Räty posted 4a0dd0ed.1070...@gentoo.org,
> excerpted below, on Fri, 15 May 2009 23:30:37 +0300:
>
>> Indeed there's no problem switching EAPIs as long as a stable Portage
>> supports the EAPI you are migrating to. Portage was buggy with this when
>> EAPI 2 was introduced
On Sat, 16 May 2009 17:43:32 +0200
Tobias Klausmann wrote:
> > That doesn't let us do version format changes.
>
> Or are we talking about the *ebuild* versions? I see that as
> different matter. Plus: You could change the version format with
> the changed extension. I sure do hope there are no pl
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 17:43:32 +0200
> Tobias Klausmann wrote:
> > > That doesn't let us do version format changes.
> >
> > Or are we talking about the *ebuild* versions? I see that as
> > different matter. Plus: You could change the version form
On Sat, 16 May 2009 17:55:01 +0200
Tobias Klausmann wrote:
> > Yes, those. The current rules include some pointless arbitrary
> > restrictions that are only there for historical reasons and that
> > mean people have to mess with convoluted MY_PV things.
>
> Still: a sane spec for those plus a san
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> Tobias Klausmann wrote:
> > > Yes, those. The current rules include some pointless arbitrary
> > > restrictions that are only there for historical reasons and that
> > > mean people have to mess with convoluted MY_PV things.
> >
> > Still: a san
On Sat, 16 May 2009 18:15:58 +0200
Tobias Klausmann wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > Tobias Klausmann wrote:
> > > > Yes, those. The current rules include some pointless arbitrary
> > > > restrictions that are only there for historical reasons and that
> > > > mean people
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > EAPI=3 etc? That would just be silly and it was the first idea I
> > got when I saw the proposal.
>
> Yes, yes we are. That's just one change, from a static string to a
> patter
On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 17:43:32 +0200
> Tobias Klausmann wrote:
> > > That doesn't let us do version format changes.
> >
> > Or are we talking about the *ebuild* versions? I see that as
> > different matter. Plus: You could change the versi
On Sat, 16 May 2009 18:31:38 +0200
Tobias Klausmann wrote:
> On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > > EAPI=3 etc? That would just be silly and it was the first idea I
> > > got when I saw the proposal.
> >
> > Yes, yes
On Sat, May 16, 2009 at 10:05:08PM +0530, Arun Raghavan wrote:
> On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote:
> > On Sat, 16 May 2009 17:43:32 +0200
> > Tobias Klausmann wrote:
> > > > That doesn't let us do version format changes.
> > >
> > > Or are we talking about the *ebuild* ver
On Sat, 16 May 2009 22:05:08 +0530
Arun Raghavan wrote:
> So from all the debate that's going on, the current major issue seems
> to be being able to support '-scm' as per GLEP-54. What other
> restrictions in the version format are you referring to?
Have a look at every package using a MY_PV sty
On Sat, 2009-05-16 at 12:39 -0400, Thomas Anderson wrote:
[...]
> For one, there's the restriction that all *-alpha/*-rc has to be
> represented _rc/_alpha. I plan on doing more research into perhaps
> lifting this restriction in a future EAPI, but this would of course
> require glep 55's solution.
On Sat, 16 May 2009 22:14:30 +0530
Arun Raghavan wrote:
> On Sat, 2009-05-16 at 12:39 -0400, Thomas Anderson wrote:
> > For one, there's the restriction that all *-alpha/*-rc has to be
> > represented _rc/_alpha. I plan on doing more research into perhaps
> > lifting this restriction in a future E
On Sat, 2009-05-16 at 17:47 +0100, Ciaran McCreesh wrote:
>
> Ok, what are all the things requiring format-break changes that we'll
> want in the next ten years? Please provide a complete list.
Don't care. Let's fix the problems we have *now* using solutions that we
can agree upon, rather than tr
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 18:31:38 +0200
> Tobias Klausmann wrote:
> > On Sat, 16 May 2009, Ciaran McCreesh wrote:
> > > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for
> > > > EAPI=3 etc? That would just be silly and it was the first
On Sat, 16 May 2009 18:54:41 +0200
Tobias Klausmann wrote:
> > Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> > of .ebuild?
>
> One that you illustrate yourself: what aboud .eapi-11.eb or
> .ebuild-11?
Then you include those in your static list not using patterns that
deals with
On Sat, 16 May 2009 22:24:04 +0530
Arun Raghavan wrote:
> On Sat, 2009-05-16 at 17:47 +0100, Ciaran McCreesh wrote:
> > Ok, what are all the things requiring format-break changes that
> > we'll want in the next ten years? Please provide a complete list.
>
> Don't care. Let's fix the problems we h
On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
[...]
> > Don't care. Let's fix the problems we have *now* using solutions that
> > we can agree upon, rather than try to foist solutions that a
> > reasonably large population of developers *don't* like (even after
> > extended debate) to s
Hi!
On Sat, 16 May 2009, Ciaran McCreesh wrote:
> Tobias Klausmann wrote:
> > > Why? What's the big deal with .ebuild-? or .eapi-?.eb instead
> > > of .ebuild?
> >
> > One that you illustrate yourself: what aboud .eapi-11.eb or
> > .ebuild-11?
>
> Then you include those in your static list not
On Saturday 16 May 2009 13:14:23 Duncan wrote:
> I mean, for the longest time, the main (among many) boosting claim seemed
> to be that the speed difference between in-file and in-filename made the
> former prohibitive in practice.
No, performance was never the point of GLEP 55. People like to ta
On Sat, 16 May 2009 19:13:21 +0200
Tobias Klausmann wrote:
> > Then you include those in your static list not using patterns that
> > deals with them.
>
> I'm unable to parse this sentence.
If you're writing a tool that deals with ebuilds, you should have a
list of EAPIs and their associated fi
On Sat, 16 May 2009 22:39:46 +0530
Arun Raghavan wrote:
> On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
> > > Don't care. Let's fix the problems we have *now* using solutions
> > > that we can agree upon, rather than try to foist solutions that a
> > > reasonably large population of de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, May 16, 2009 at 01:11:34PM +0200, Ben de Groot wrote:
> David Leverton wrote:
> > But the point isn't that we want to be able to do those things. The point
> > is
> > that if the EAPI is in the filename, it's blatantly obvious that it has to
On Sat, 16 May 2009 13:10:07 -0500
William Hubbs wrote:
> Agreed. The way I have always usedEAPI is, you set it once at the top
> of the EBUILD and you are done with it. As far as I know, there is no
> reason to change EAPI once it is set, and eclasses shouldn't be
> changing it.
But eclasses h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, May 16, 2009 at 07:14:00PM +0100, Ciaran McCreesh wrote:
> On Sat, 16 May 2009 13:10:07 -0500
> William Hubbs wrote:
> > Agreed. The way I have always usedEAPI is, you set it once at the top
> > of the EBUILD and you are done with it. As far
On Saturday 16 May 2009, Ciaran McCreesh wrote:
> Have a look at every package using a MY_PV style thing. Group those
> into "upstream's doing something dumb" and "upstream's being sensible
> but our arbitrary restrictions on rules means we can't follow what
> they do".
I like the fact that our ve
On Sat, 16 May 2009 20:38:30 +0200
Robert Buchholz wrote:
> I like the fact that our versioning rules are a fixed subset of the
> sum of all our upstream's versioning rules. It provides a more
> consistent user experience.
>
> As a user, I know it's always "_rc" and never "-rc". Gentoo
> developer
On Sat, 2009-05-16 at 18:55 +0100, Ciaran McCreesh wrote:
[...]
> You have yet to provide an alternative for fixing the arbitrary and
> pointless version format restrictions that are currently in place.
Create an EAPI for the required changes, fast track inclusion to a
stable portage.
If this is
Nirbheek Chauhan wrote:
The statistics are irrelevant. Go ahead and count how many posts have
been made about GLEP55 and 54 since they were introduced.. Now please
compare with how many posts have been made about maintainer-wanted.
Then perhaps you will see what I mean by "useless talk".
You ma
Alexey Shvetsov wrote:
its realy a good idea to make targets for qemu selectable =) since not all
targets work all time at the same condition.
By tomorrow I'm going to push the use_expand changes and the unified
qemu ebuild.
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http
On Sun, 17 May 2009 00:42:58 +0530
Arun Raghavan wrote:
> On Sat, 2009-05-16 at 18:55 +0100, Ciaran McCreesh wrote:
> [...]
> > You have yet to provide an alternative for fixing the arbitrary and
> > pointless version format restrictions that are currently in place.
>
> Create an EAPI for the req
David Leverton wrote:
> For comparson, another alternative that some people have suggested is putting
> it in a specially formatted comment. This avoids the issue I mentioned
> because bash doesn't try to parse those at all, so the only rules are those
> that specify what format the comment sho
Joe !
How are you doing ? I've been meaning to call you but I've been busy
as hell due to the move. Do you want to have a beer or lunch sometime
?
Denis.
Oops, that was supposed to be sent to him directly. Sorry about that.
Denis.
On Sat, May 16, 2009 at 2:11 PM, Denis Dupeyron wrote:
> Joe !
>
> How are you doing ? I've been meaning to call you but I've been busy
> as hell due to the move. Do you want to have a beer or lunch sometime
> ?
>
> Den
On Sat, May 16, 2009 at 8:19 AM, Ciaran McCreesh
wrote:
> Because the way Gentoo works, any objection to a proposal, valid or not,
> whether or not it's already been addressed, has to be answered before a
> proposal gets anywhere. Thus, every time people post nonsense about
> GLEP 55, every post h
On Sat, 16 May 2009 15:13:50 -0600
Denis Dupeyron wrote:
> If the author had documented these objections and the answers in the
> glep then it would have made it possible to avoid most of what you
> call the nonsense.
Except that at the last Council meeting, there were complaints that
objections
On Sat, May 16, 2009 at 3:18 PM, Ciaran McCreesh
wrote:
> Except that at the last Council meeting, there were complaints that
> objections *had* been included and discussed in the GLEP, and claims
> that including such material made the GLEP less clear.
As unfortunate as it is, council members ha
On Sat, 16 May 2009 15:27:59 -0600
Denis Dupeyron wrote:
> > This is another of those issues where whichever way it's done, some
> > people complain.
>
> As long as you go by the rules those who complain about you doing so
> are wrong. I've been told you were not the kind who was afraid of
> bein
Patrick Lauer gentoo.org> writes:
>
> For quite some time (over a year, actually) we've been discussing the
> mysterious and often misunderstood GLEP55.
> [http://www.gentoo.org/proj/en/glep/glep-0055.html]
>
> The proposed solution to a problem that is never refined, in short, is to add
> the
On Sat, 16 May 2009 21:58:10 + (UTC)
Mark Bateman wrote:
> "The current way of specifying the EAPI in ebuilds is flawed"
> That is not defining the problem, that is an opening statement.
That is the problem.
> "In order to get the EAPI the package manager needs to source the
> ebuild, which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> On Sat, 16 May 2009 22:39:46 +0530
> Arun Raghavan wrote:
>
>> On Sat, 2009-05-16 at 17:59 +0100, Ciaran McCreesh wrote:
>>
Don't care. Let's fix the problems we have *now* using solutions
that we can agree upo
On Sat, 16 May 2009 16:39:40 -0700
Nick Fortino wrote:
> Given the above, it should be clear that any argument which states
> some future improvement to the ebuild format will be impossible based
> upon making the wrong choice between proposal 1 and proposal 2 must be
> invalid, as they have the
Nick Fortino wrote:
> Such a transformation is possible, given the restrictions on arg, as
> well as ebuild format.
Isn't this a bit circular? The whole point of wanting to change the
extension is to get rid of exactly these restrictions; if you assume the
restrictions, then the whole thing is kin
Nick Fortino posted 4a0f4ebc.5020...@gmail.com,
excerpted below, on Sat, 16 May 2009 16:39:40 -0700:
> line 5 shall contain the string EAPI="arg"
Given the bash expansion properties associated with double-quotes, that's
not really going to work as such. What if "arg" contains $var, where
$va
On Sun, 17 May 2009 00:35:45 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> As for ciaranm's argument that you're restricting changes to the
> version string, say allowing -rc where _rc is now required, one-time
> restriction of a year or two, yes. However, if the spec is crafted
> such that t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All,
I just submitted a patch today to fix an issue with brltty and it was
partially accepted.
The part of it that wasn't accepted is what brings me to this list.
I was told by the brltty developers that localstatedir should be /var.
I noticed, howe
There's been a lot of noise on this list the past few days about GLEP
55, but precious few solutions actually proposed. Changing the file
extension would certainly be useful for some changes, but the success of
EAPIs >0 which are already in the tree demonstrates that for many
changes, altering the
Ciaran McCreesh wrote:
> On Sat, 16 May 2009 16:39:40 -0700
> Nick Fortino wrote:
>
>> Given the above, it should be clear that any argument which states
>> some future improvement to the ebuild format will be impossible based
>> upon making the wrong choice between proposal 1 and proposal 2 m
Ciaran McCreesh posted
20090517015039.2fa04...@snowmobile, excerpted below, on Sun, 17 May 2009
01:50:39 +0100:
> On Sun, 17 May 2009 00:35:45 + (UTC) Duncan <1i5t5.dun...@cox.net>
> wrote:
>> As for ciaranm's argument that you're restricting changes to the
>> version string, say allowing -r
Ciaran McCreesh googlemail.com> writes:
>
> On Sat, 16 May 2009 21:58:10 + (UTC)
> Mark Bateman soon.com> wrote:
> > "The current way of specifying the EAPI in ebuilds is flawed"
> > That is not defining the problem, that is an opening statement.
>
> That is the problem.
No, that is a summ
Ravi Pinjala wrote:
Nick Fortino wrote:
Such a transformation is possible, given the restrictions on arg, as
well as ebuild format.
Isn't this a bit circular? The whole point of wanting to change the
extension is to get rid of exactly these restrictions; if you assume the
restrictions, then th
Duncan wrote:
So I believe the cost to be quite reasonably managed, after all.
Benchmarks would of course be needed to demonstrate that, but I believe
it worth pursuing.
Agreed. Perhaps I'm just spoiled by RDBMS's at work or something, but
it seems like we're trying to squeeze every ounce
Ciaran McCreesh wrote:
The only way it'll be "in the next ten years" rather than "in the next
two years" is if Gentoo continues its current approach of making
changes require every single person to agree...
Frankly, I won't be at all surprised if this thread (in some form) is
still going on i
On Sat, 2009-05-16 at 20:21 +0100, Ciaran McCreesh wrote:
[...]
> Can't do that. The package manager has to barf on unrecognised .ebuild
> files.
I assume the reasons are the same as below.
> > If this is not viable, make an unrecognised version string cause the
> > same fallback as an unsupport
83 matches
Mail list logo
