ations I claim we don't fully understand because no-one has
specified what the exact general problem is (although lots of people
have looked at one particular case and assumed that their case holds
for everything, which isn't true).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
RDEPENDing on glib:2.30 to
> glib:2.32? :O
Noo. You'd use := dependencies, possibly with a >= constraint.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
to try to skip "ABI_SLOT" way?
No-one's ever implemented it, or knows how it works, or knows what
exactly it's supposed to do. The only advantage ABI_SLOT has is that we
don't know what its limitations are, other than that it doesn't
solve any new problems (alth
"an idea" to the kind
of knowledge we want to have. Think REQUIRED_USE for how this can go
wrong...
If you think ABI_SLOT is essential, why not try implementing it and
trying it out in a large number of packages, and reporting your results?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
strongly encourage people to make proper use of slots
to avoid having mass breakages and annoyances on user systems, even if
it means more work for developers. Broken linkage due to an upgrade
really shouldn't happen.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 06 Jun 2012 14:45:55 -0700
Zac Medico wrote:
> Can you explain how Exherbo is handling dbus-glib rebuilds after
> glib:2 updates?
Badly, most likely.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ssing out on a brilliant opportunity to encourage developers
put in a bit more work to save users a huge amount of pain here.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
k for a developer to get it right than
it is for a user to deal with it", you can use blockers.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ys who go out of their way to make it hard to
slot things.
> > Broken linkage due to an upgrade really shouldn't happen.
>
> It's certainly not ideal, but wouldn't it be useful to have the
> flexibility to accommodate it? Let's be practical.
Blockers plus SLOT provides that flexibility.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 07 Jun 2012 10:47:19 -0700
Zac Medico wrote:
> On 06/06/2012 11:12 PM, Ciaran McCreesh wrote:
> > On Wed, 06 Jun 2012 14:45:55 -0700
> > Zac Medico wrote:
> >> Can you explain how Exherbo is handling dbus-glib rebuilds after
> >> glib:2 updates?
> &g
rg/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b
>
> looks like "*" usage for SLOTs would be allowed :), or I am
> misinterpreting it?
It's not a wildcard.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ts in a future EAPI.
> For the slot-operator case, will every consumer of libpng be forced to
> change their dep to libpng:= to ensure they get rebuilt when libpng
> bumps from 1.5 to 1.6??
Every consumer of libpng that wants to improve from the current
situation, yes.
- --
Ciaran McCre
, then try converting lots
of ebuilds with and without being able to use ABI_SLOT.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
". Then you
can do explicit :2/2.32 dependencies if you like, or :2 (which would
match SLOT="2" or SLOT="2/anything"), or :2= (which gets rewritten
to :2/2.32=) or :2*. If an ebuild does SLOT="2", it's treated as 2/2.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
sed versions have -r3xx revision numbers and go in
> slot 3).
That is not what revisions are for. If you can't solve a problem
properly using existing mechanisms, ask for new ones.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 10 Jun 2012 22:27:07 +0200
hasufell wrote:
> On 06/10/2012 10:19 PM, Ciaran McCreesh wrote:
> > On Sat, 09 Jun 2012 23:54:21 -0400
> > Alexandre Rostovtsev wrote:
> >> For libraries, if possible, try splitting gtk2 and gtk3 support
> >> into different s
On Sun, 10 Jun 2012 21:45:27 +0100
Nirbheek Chauhan wrote:
> On Sun, Jun 10, 2012 at 9:19 PM, Ciaran McCreesh
> wrote:
> > On Sat, 09 Jun 2012 23:54:21 -0400
> > Alexandre Rostovtsev wrote:
> >> For libraries, if possible, try splitting gtk2 and gtk3 support
> &g
On Mon, 11 Jun 2012 13:15:40 +0100
Nirbheek Chauhan wrote:
> On Sun, Jun 10, 2012 at 9:49 PM, Ciaran McCreesh
> wrote:
> > On Sun, 10 Jun 2012 21:45:27 +0100
> > Nirbheek Chauhan wrote:
> >> It's a simple workaround for the lack of proper ebuild namesp
to use that better
> way in the future. If you (or any) have some suggestion, it would be
> nice :)
It is handled better by working out what exactly the problem is, and if
you can't implement it nicely using existing features, then not
implementing it at all until you have suitable fe
we'll present the EAPI 5 branch to the Council and have
them vote on each individual feature. Then we'll cherry-pick the ones
they approve to master.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
for earlier EAPIs. But what you
shouldn't do is expect a feature to be introduced just based upon a two
sentence description, because the best outcome there is that we end up
giving you something approximately related to what you wanted...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
process. Figuring out what we're trying to solve is far harder than
writing a bit of code.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
would be uncovered with this (but maybe I am
> wrong as I know Zac had a more clear conception about how this
> ABI_SLOT way would work and what would it cover)
Somehow I don't think this cunning plan has been thought all the way
through...
Coming up with a "solution" rather than a description of the problem is
the wrong thing to do.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
. Let's call them sub-slots instead.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 16 Jun 2012 17:24:22 +0200
Peter Stuge wrote:
> Ciaran McCreesh wrote:
> > > Could it work to make automatic signatures of imported ABI, and
> > > simply compare signatures when a provider package is updated?
> >
> > No.
>
> Can you say why?
T
On Sat, 16 Jun 2012 17:16:34 +0200
Pacho Ramos wrote:
> El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió:
> > On Sat, 16 Jun 2012 16:48:20 +0200
> > Pacho Ramos wrote:
> > > Regarding the comparison with using only SLOT, the most clear
> > > examp
sub-slots, in any case.
>
> Well, probably the problem is to predict when will that be really
> solved there :(
Naah. This is one of those things that requires developers to put quite
a lot of exta effort in to their packages in order to improve the
quality of experience for users, which means it's not going to be
suitable for Gentoo's development model.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
> Sounds interesting, but I don't fully understand. Can you give an
> example ebuild?
Suggested dependencies were used in the old kdebuilds, and Exherbo
makes extensive use of both suggested and recommended dependencies, so
there are plenty of examples, spec wording and an implementat
et the resolver to do them cleanly. Once the
package mangler side is done, experience has shown that there will be a
very short delay before every relevant package is using it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 17 Jun 2012 03:35:08 +0200
hasufell wrote:
> On 06/16/2012 08:14 PM, Ciaran McCreesh wrote:
> > Suggested dependencies were used in the old kdebuilds, and Exherbo
> > makes extensive use of both suggested and recommended depen
b.
I'm pretty sure we can't go anywhere with this until all the things
that manually access VDB are gone. Can you work on that first?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 17 Jun 2012 22:31:59 +0200
Michał Górny wrote:
> A simple solution to a program long-unsolved. In GLEP form.
>
> Both attached and published as a gist:
>
> https://gist.github.com/2945569
Do you have an implementation we can play with?
--
Ciaran McCreesh
signature.
erbo allows suggestions to be grouped, described and
taken by feature. It's done via annotations (the same mechanism used to
provide decent handling of blockers etc). Search for "group-name" in
exheres-for-smarties for an example.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Tue, 19 Jun 2012 20:16:39 +0200
Thomas Sachau wrote:
> Since there is again no response at all, it seems like everyone is ok
> with this, so i will propose to add this to the next council agenda
> for EAPI-5 addition.
Got a diff for PMS?
--
Ciaran McCreesh
signature.asc
Descrip
On Tue, 19 Jun 2012 20:54:07 +0200
Thomas Sachau wrote:
> Ciaran McCreesh schrieb:
> > On Tue, 19 Jun 2012 20:16:39 +0200
> > Thomas Sachau wrote:
> >> Since there is again no response at all, it seems like everyone is
> >> ok with this, so i will propos
specially thinking about the setup of the environment and the
> code details for the wrappers for binaries and headers, hardcoding
> those details into PMS makes it hard to change/fix issues later on.
Sounds like you haven't really got a clean design then.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
tten. We don't need a bug to track it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 20 Jun 2012 13:12:25 +0200
Michał Górny wrote:
> On Wed, 20 Jun 2012 12:02:42 +0100
> Ciaran McCreesh wrote:
> > Please don't. User patches were discussed on this list, and there's
> > already wording written. We don't need a bug to track it.
>
>
builds to support user packages. This was all covered in the
original thread.
> nor any function to actually apply patches...
Moving epatch into EAPI 5 is a separate feature, and one that's
probably going to be controversial.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Wed, 20 Jun 2012 17:44:36 +0200
Ulrich Mueller wrote:
> >>>>> On Wed, 20 Jun 2012, Ciaran McCreesh wrote:
> > I believe we consider the user patches feature to be finalised,
> > [...]
>
> I disagree with this. As it is currently worded, every ebuild woul
7;t call eautoreconf, in the first
> place. Should we require that all of them inherit autotools now, just
> for the unlikely case that user patches could be applied?
If the aim is to provide a working feature to users, yes. The
alternative is to not provide user patches support.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
st restrict the arguing to
being between SDEPEND and DEPENDENCIES? Cheers.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
uld be
> the exception and not the rule.
So far as I know, every PM relies heavily upon bash anyway (and can't
easily be made not to), so even if developers would accept having to
rewrite all their eclasses, it still wouldn't remove the dep.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
(on a glibc system)?
Nobody knows, since everyone you ask has a different idea of what
multilib is.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Jun 2012 16:50:33 -0400
Richard Yao wrote:
> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
> > wrote:
> >> Multilib (and/or multiarch) support The current bin
> shell.
>
> I do not see any technical problem.
Package managers don't "source the ebuild"... You should take a look at
the amount of horrible bash code the three PMs have, and see why it's
there.
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Vers
implement it independently or produce a PMS patch.
General consensus seems to be that it needs a GLEP and a proposed diff
against PMS before anyone can even reasonably pass comment on it, let
alone accept it.
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Li
On Wed, 20 Jun 2012 23:43:36 +0200
Justin wrote:
> On 20.06.2012 22:35, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400
> > Richard Yao wrote:
> >> Multilib (and/or multiarch) support
> >>The current binaries cause a great deal of pain,
>
accepted by the expendable figurehead, and then rolled out.
> or maybe I am wrong and people is able to use any PM manager
> compliant with EAPI on exherbo without issues?
If anyone ever manages to come up with another package mangler that can
get close to implementing what Exherbo needs, then sure.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 21 Jun 2012 09:29:49 +0200
Michał Górny wrote:
> On Wed, 20 Jun 2012 18:24:33 +0100
> Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 19:11:33 +0200
> > hasufell wrote:
> > > On 06/20/2012 07:07 PM, Michał Górny wrote:
> > > > Please read the r
x27;s not about forcing anything. The point of the EAPI
process is to allow Gentoo to roll things out without requiring
developers to rewrite all their ebuilds every few months (which
happens on Exherbo, incidentally), and without breaking user systems.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
don't think so. 'Implemented
> in Paludis' doesn't work here. We're discussing Gentoo features,
> and official package manager in Gentoo is portage. If you don't
> believe me, check out the docs.
And since when was "Implemented in Portage" a requirement
ost of them". Nearly all of them got
implemented quickly. Our policy on this has always been "ask Zac
whether he thinks they're reasonably quick to implement".
But you know this, so kindly keep your disruption to places where
you're right.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
> matter of waiting until the next EAPI is finalized (which currently
> runs at a glacial pace of about one EAPI a year as far as I remember)
I like how you simultaneously troll both sides of that issue. Weren't
you previously claiming there were too many EAPIs and that we shouldn't
have lots of new ones?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
en they need to learn how.
That's not the issue. The issue is advertising a user patches feature
when there's no way for the user to know up-front whether or not their
patches will be applied. This whole discussion started because user
patches are currently randomly ignored sometimes
On Thu, 21 Jun 2012 07:11:27 -0500
Homer Parker wrote:
> On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
> > In case you're not aware, the first time Gentoo did multilib, it was
> > done as a series of random changes to Portage that no-one really
> > thought
ull time on
providing basic tutoring and hand-holding on design and technical
writing -- it's not really my cup of tea. But if you have the money,
there are plenty of others who make their livings teaching that sort of
thing.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
than on bogus stats.
>
> Well at least I added some data to undermine my request. Your turn
> now.
Oh, I think your request is fine, and your results are reasonable. I
just think letting anyone who can say with a straight face that they
should be there be there is a better measure than numb
hat your colleagues are claiming here. I suggest if
you're upset at the suggestion that Gentoo doesn't have a decent
multilib implementation then you take it up with all the people who are
demanding the PMS team provide them with one.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Thu, 21 Jun 2012 23:01:15 +0200
Michał Górny wrote:
> Just a short note as it seems some confusion arises lately:
>
> Ciaran McCreesh is not a Gentoo dev and his words don't represent
> the position of Gentoo development team.
Right. Doesn't that make me more impo
you're assuming that "the work"
is trivial, which for some of the things you're discussing it really
isn't. The PMS wording is the trivial bit that comes at the end once
the problem and solution have been worked out.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ing for that aren't magically appearing are hard.
I'll remind you that for "big" features, the GLEP process is already
documented.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
rns rather than
making their case for the introduction of a horse?
--
Ciaran McCreesh
signature.asc
Description: PGP signature
27;s going
nowhere because what's been presented so far is nowhere near enough
that anyone *can* help, and requests for a better description of what
we're supposed to be looking at are being met with complaints that we
haven't magically done all of the remaining work (which on this one I
suspect is far more effort than what's been done so far).
--
Ciaran McCreesh
signature.asc
Description: PGP signature
an's description of it as an "opaque list of things" is
pretty much spot on. That's why we want a GLEP and a PMS diff -- an
attempt at those might bring this to the point where we can say
something other than "huh?".
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 23 Jun 2012 13:52:24 +0200
Peter Stuge wrote:
> Ciaran McCreesh wrote:
> > bring this to the point where we can say something other than
> > "huh?".
>
> You can accelerate by making one guess about each thing on the list
> and asking for confirmation o
3. So again, whether or not
that ends up in EAPI 5 is just a matter of timing and Council approval.
For "what's being worked on", you just need to look at the PMS list.
So I'm really not sure what your problem is there...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
e Council. That's all there is to it. There is no
lengthy form P123b.5 to fill in or anything like that.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ing for a feature that allows you to solve it
properly, rather than abusing existing features to do something they're
not intended for.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
hen you should be mailing the list and asking for QA or
Council approval, rather than doing it and then asking for forgiveness
later.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ore
PROPERTIES tokens. It won't solve the abuse, but it will allow the
impact upon users to be lessened.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
7;s not a severe
enough problem to warrant a hack until a nice alternative is available.
> Shall we add that subject to next council meeting or do we just wait
> for QA's opinion here ?
I'd like to know why using USE flags until a nicer solution is available
is sufficiently terr
are being used to
mean "with a different Ruby implementation" or "built in a different
way", which screws up the meaning.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
doing weird things with versions and slots.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 23 Jun 2012 16:45:09 +0200
Gilles Dartiguelongue wrote:
> Le samedi 23 juin 2012 à 14:40 +0100, Ciaran McCreesh a écrit :
> > I'd like to know why using USE flags until a nicer solution is
> > available
> > is sufficiently terrible that it warrants a hackarou
option Paludis provides for users, but doing so leads to old
versions of things lying around when an upgrade is preferred. It's also
incorrect behaviour when multiple slots are capable of satisfying a
dependency.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
hat is really going
> wrong.
As I've already said, this isn't about solving the root cause. It's
about reducing the impact of damage that's already been done until the
root cause is solved properly.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 23 Jun 2012 18:47:26 +0200
Justin wrote:
> On 23.06.2012 18:17, Ciaran McCreesh wrote:
> > On Sat, 23 Jun 2012 18:13:23 +0200
> > Justin wrote:
> >> Did you read what you wrote and thought about what you request from
> >> others? Probably you better sho
going to garner much adoption.
You mean, instead of implementing trivial marking, which takes
developers a few seconds, you want to screw over users? I think that
says a lot about Gentoo's attitude...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
newer than -r200, and so will treat "the gtk3
version" or "the jruby version" as being newer versions of "the gtk2
version" or "the ruby 1.8 version", just as it tries to bring in a
newer GCC and so on.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
trivial. That's the point.
> It could be that instead of Gentoo tagging a bunch of ebuilds, you
> just change your resolver heuristic a bit.
The resolver heuristic is correct, except in the cases where people are
doing utterly weird things with revisions and slots.
--
Ciaran McCreesh
t;, just as it tries to
> > bring in a newer GCC and so on.
>
> And what problems is that causing for you?
The problem is that there's no way of knowing that -r300 is not "a
newer version" than -r200, and that the jruby implementation is not "a
newer version" than the ruby 1.8 implementation.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 23 Jun 2012 19:54:13 +0200
Michał Górny wrote:
> On Sat, 23 Jun 2012 18:45:46 +0100
> Ciaran McCreesh wrote:
> > On Sat, 23 Jun 2012 19:43:10 +0200
> > Pacho Ramos wrote:
> > > > It treats -r300 as being newer than -r200, and so will treat
> >
ce some random 'funky' word for a single ebuild.
> Or.. since it's just a single package, maybe you would just add an
> ignore list to paludis.
a) it's not a single package, and b) ignore lists in a package manager
is a terrible idea.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 23 Jun 2012 20:23:13 +0200
Michał Górny wrote:
> On Sat, 23 Jun 2012 19:06:38 +0100
> Ciaran McCreesh wrote:
> > On Sat, 23 Jun 2012 20:09:03 +0200
> > Michał Górny wrote:
> > > > That's just it, though -- this no longer holds. -r300 is now
>
should avoid doing that until we have a good solution
in place.
Or, looking at it another way, Portage's upgrade rules shouldn't be
locked in place because of weird behaviour from a few packages.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
this info, it's called a "slot dependency".
It's not a property of individual packages that happen to depend upon
the problematic package. The property holds or not for a package
regardless of whether anything depends upon it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
ge mangler now needs a
way of knowing that for a certain few packages, bringing in new slots
when not explicitly required is undesirable.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sat, 23 Jun 2012 22:27:03 +0300
Alex Alexander wrote:
> On Sat, Jun 23, 2012 at 10:16 PM, Ciaran McCreesh
> wrote:
> > On Sat, 23 Jun 2012 22:14:32 +0300
> > Alex Alexander wrote:
> >> If it is a package without reverse dependencies, updating to the
> >
On Sat, 23 Jun 2012 22:36:14 +0200
Marien Zwart wrote:
> On za, 2012-06-23 at 17:08 +0100, Ciaran McCreesh wrote:
> > > Is it that Paludis installs a newer SLOT even if a reverse
> > dependency
> > > explicitly requests another SLOT? Sounds like a bug to me.
>
he problem is that -r and slots are being used to do something weird.
The proper solution is going to be long term, from the looks of things.
This is a short term damage control operation.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
On Sun, 24 Jun 2012 13:21:01 +0200
Michał Górny wrote:
> On Sun, 24 Jun 2012 11:58:07 +0100
> Ciaran McCreesh wrote:
> > On Sun, 24 Jun 2012 10:19:19 +0200
> > Michał Górny wrote:
> > > > Think || ( a:3 a:2 ).
> > >
> > > So now that you&
On Mon, 02 Jul 2012 19:06:43 +0200
Thomas Sachau wrote:
> The problem here is the following: How do you know before the
> src_install phase, that a package has no ABI-specific content?
You make every package that has ABI specific content explicitly say so,
as metadata.
--
Ciaran Mc
On Tue, 3 Jul 2012 15:44:04 +1200
Kent Fredric wrote:
> Firstly, we already have a ^^( ) syntax for REQUIRED_USE , "one of,
> but not more than one of".
A user has a and b installed. c depends upon ^^ ( a b ). The user tries
to install c. What happens?
--
Ciaran McCreesh
On Tue, 3 Jul 2012 20:24:43 +1200
Kent Fredric wrote:
> On 3 July 2012 19:08, Ciaran McCreesh
> wrote:
> > On Tue, 3 Jul 2012 15:44:04 +1200
> > Kent Fredric wrote:
> >> Firstly, we already have a ^^( ) syntax for REQUIRED_USE , "one
> >> of, but not mo
gt; just an eclass like the others and ebuilds should make sure they
> inherit it if needed?
base.eclass is a historical mistake, from before the design of eclasses
was fully figured out and moved into the package manager. Unfortunately,
rather than letting it die, people keep putting things in
cope variables to enhance default phase functions.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
gt; become useless
Perhaps you should view the Council's vote as advice that passing
arguments that way is unpopular and unlikely to endear you to your
fellow developers.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
;s some disgusting code in some
eclasses that sort of relies upon its format being sort of right. We
have yet to manage to do away with that code, which is annoying,
because VDB's format stinks.
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAY
They shouldn't take you more than a couple of hours.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
1201 - 1300 of 3510 matches
Mail list logo
