FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-27-2012, 07:53 PM
Brian Harring
 
Default Addressing GLEP-62 itself

On Wed, Sep 26, 2012 at 07:25:11PM -0300, Alexis Ballier wrote:
> On Wed, 26 Sep 2012 14:02:57 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > On Wed, Sep 26, 2012 at 02:38:02PM -0300, Alexis Ballier wrote:
> > > IUSE_RUNTIME is optional for PMs, why does the UI matter at all ?
> > > Also, the proposal doesn't assume flags are toggable at will, it
> > > assumes they are useflags and obey the same rules.
> >
> > I truly hate claims like this; "it's optional, so who cares if it's
> > whacky". Think through the proposal; for it to work reliably, it's
> > not optional. Same issue I've been y'all over the head with,
> > rendered/finalized vs raw/unfinalized deps being stored in the VDB.
> >
> > All managers have to write unfinalized if that proposal goes through,
> > even if they don't support the optional toggling after the fact.
>
> Why? _Current_ PMs will rebuild the package. The point of this is just
> to give them a hint that they do not need to rebuild it. We already
> have an implementation actually: one that ignores the hint

Bullshit. This is optional in the sense of embrace/extend 'optional';
if one PM takes up the new functionality, all have to switch to
writing unfinalized deps to the VDB, and all have to switch to
transfering that IUSE_RUNTIME crap to the VDB.

If they don't, whatever sole/crappy PM that runs w/ this proposal will
wind up forcing rebuilds on any packages merged by the PM's that don't
do this "optional" glep.

Thus rendering it nonoptional since it implicitly is reliant on all
switching to the degrade *DEPEND writing that this proposal is reliant
on. The blame game becomes "well, you shouldn't use the PMs that
don't do this *optional* thing". There in is the implicit lie of that
'optional' crap.

Claiming other wise is ignoring reality; I called it embrace/extend
because this is exactly how that shit goes- sure it's optional, 'cept
you're forced to support it (even partially) else the whole degrades
and that PM winds up getting blackballed or fragmentation occuring.
As far as I'm concerned, any PMS intended proposal must not pull the
'should' or 'optional' crap; it has no place in a spec (spec's are
supposed to be assertions after all).


> > As for the UI... arguing "but it's optional!" doesn't give a blank
> > check for the UI angle. What the plan, more colorization and a new
> > char for emerge -vp? Because we're kind of running out of chars
> > there...
>
> How is this relevant ?

Um... dude... This proposal is about adding suggested/optional deps so
people can inspect/select/enable them per package.

You're asking "how is the UI relevant" in light of that.

Just saying; it's kind of core to this whole damn thing, else we're
just trying to add an optimization hack; either one runs a strong risk
of my next response including a joke about elderberries and hamsters.



> > It's a simple enough request; one that wouldn't even need to be made
> > if there was code backing this proposal; on a related note, hell yes
> > I'm wary of having this dumped on manager authors heads and having to
> > be told "sort out the mess/make it so". So I'm asking y'all to at
> > least put in an equivalent time investment doing a quick prototype.
> >
> > This isn't an unreasonable request, and has been the norm for most
> > gleps for a long while.
>
> I guess people do not want to invest time in writing code for something
> doomed.

This is one of the cases where "tough fucking luck" really/truly fits.

If it's doomed, consider why it's doomed. I'm not requiring a
prototype just because I'm a dick; I'm requiring a prototype because
I fully expect since y'all won't listen to what people are telling
you, trying to write the code will educate y'all to what we've been
saying. This is ignoring that prototypes are bsaically the norm for
proposals of this sort (both PMS and gleps)... meaning it's the
standard, and y'all are trying to get this proposal special cased.

Does it suck you can't just get what you want via writing a quick doc
and arguing on an ml? At times, yes. If you believe it's worth it,
you do the legwork.

If the folks backing this can't be bothered to write a freaking patch,
well, I think that's a pretty strong vote of no-confidence on the
backers part.


> The original request was just to have it 'accepted' so that an
> implementation can start. If the implementation is good then make it
> final, otherwise amend or reject the glep. This isn't unreasonable
> either.

Also known as rubber stamp it. And if it sucks, of course it's easy
to roll that bad idea back? Right?

If the idea was universally accepted and lacked issues, that may fly;
that's not been the case.


> > It cannot be stacked because y'all are trying to shove this in as an
> > optional; unlike it's brother IUSE, which stacks.
> >
> > As for "ons of others that don't stack"; very few actually influence
> > the package manager; ~14 roughly, minimally 5 of those stack (those
> > that don't, basically aren't lists).
>
> So it's not stacked, nothing else to discuss here

Grr. You're being daft if you think I'll back down just because of
some word play and ignoring my points.

It *should* be stacked is my view; that matches it's sibling IUSE, and
general behaviour for metadata lists.

However, that cannot be done if it's treated as 'optional'- that
'optional' crap was attempted as a way to glue this onto existing
EAPIs. I'm pointing at the metadata issue since 1) that optional
requirement results in the metadata key being ill fitting in
comparison to IUSE, 2) it's easier to beat on that point then to have
to argue w/ y'all as to the fact y'all are ignoring the implicit
requirement of this proposal that IUSE_RUNTIME get added into the
mainline caches (without it, more PM hacks would be required;
additionally, the metadata cache angle is a further example of this
being non-optional).


> > > """
> > > Package managers not implementing this GLEP will consider
> > > the ``IUSE_RUNTIME`` variable as an irrelevant bash variable
> > > """
> > > """
> > > 2. introduce additional ``IUSE_RUNTIME`` variable listing names of
> > > USE flags related to optional runtime dependencies (without prefixes
> > > related to IUSE defaults).
> > > """
> > >
> > > Treating bash variables as bash variables is rather the norm,
> > > stacking is the exception. As I understand it, your only objection
> > > here is that you want to see written 'IUSE_RUNTIME gets no special
> > > treatment' in the proposal ?
> >
> > My objection is punting it to the council till it's actually nailed
> > down/sane; having them mark it accepted means we're stuck w/ the
> > results if it turns out to be shit at the implementation/UI level as
> > a lot of us think it will be.
> >
> > So yes, I want it actually finalized. Bluntly; there's zero point
> > having the council comment if it ain't finalized.
>
> Then the proposal itself should be discussed, not the implementation
> details: chars for emerge -pv are irrelevant; you pointed the raw dep
> issue in the VDB, that's good, but never said anything as of why they
> can't additionally be stored, making this a non-issue for the
> _proposal_ acceptation.
>
> Anyway, without implementation I expect the council to just give a vote
> of opinion, showing support or non-support to the proposal; the
> proposal will be final only once the council will be happy with
> portage's implementation. And I agree, the council doesn't need to be
> involved to start the implementation, but knowing this proposal has
> supporters will motivate people to do the implementation, vs. not even
> being sure the idea itself will get some support.

I reiterate; if a proposal needs the council to motivate people, that
proposal is fucked- period. If the backing author(s) can't be
bothered to do the implementation, it's doubly so fucked. Trace
gentoo's history before arguing that one- there is a lot of examples
already.

You can phrase it, argue it, whatever, all you want, but that's a fact
of reality. We've had lots of things get pushed up to the council and
get 'approved', ie rubber stamped- and a lot of them went jack-all
nowhere because approval != reality, nor does it even mean "of course
someone will step up to do the work you refuse to do". If you can't
do the work yourself (or won't allocate the time to do so), or can't
convince someone to do it on your behalf, the proposal is
effectively dead already.

The Heinlein "There ain't no such thing as a free lunch" quote is dead
on in this regard; you want it, do the work. Involving the council
just wastes their time, and our time via this argument continuing.


> Would you support the proposal if you are happy with its
> implementation ?

The implementation frankly isn't for me; y'all might manage something
unexpected, but I've been laying out- much more so than the people
pushing this- exactly what is going to be involved here, and the
problems involved and why I've been -1'ing this bugger from day one..
As said, y'all may surprise me, but I expect the implementation to
prove my points.

And... now the argument will be "well why should we waste our time
doing it?".

A rather valid question I'd ask in that case is "if you respect my
views enough that you'd *skip* doing the implementation if I said it
was fucked, why were you freaking arguing and trying to railroad
it through the council?"... just saying.

The reason to do the implementation is that if y'all think everyone
else is wrong on this, do the legwork to prove them wrong, prove the
idea works.

Arguing on the ML, needling people about "well this would've solved
it" (see ciaran's labels behaviour from the last N years) aren't
productive. Produce code, or shut up, basically; that's roughly the
productive courses of action at this point.

I do want suggested/optional depends; I just don't want this mess
jammed in since it doesn't solve it particularly well (and that's
being generous in my word choice), and the associated cost isn't
worth the gains in my view. That simple.

Either way, if you'd like to keep trading blows, try pushing it to
the council despite people bitching... have at it, albeit by yourself
. I've made my points, done with this thread (sparing people more
emails).

~harring
 
Old 09-27-2012, 08:13 PM
Zac Medico
 
Default Addressing GLEP-62 itself

On 09/27/2012 12:53 PM, Brian Harring wrote:
> Bullshit. This is optional in the sense of embrace/extend 'optional';
> if one PM takes up the new functionality, all have to switch to
> writing unfinalized deps to the VDB, and all have to switch to
> transfering that IUSE_RUNTIME crap to the VDB.

I think the proposal suddenly becomes a lot saner if it's done as an
EAPI extension, the optional runtime deps and IUSE_RUNTIME conditionals
are isolated in a new separate variable (perhaps SRDEPEND), and
IUSE_RUNTIME is not allowed to intersect with IUSE. Using a separate
SRDEPEND variable means that the package manager only has to preserve
USE conditionals in the vdb for that one variable.
--
Thanks,
Zac
 
Old 09-27-2012, 08:30 PM
Ian Stakenvicius
 
Default Addressing GLEP-62 itself

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 27/09/12 04:13 PM, Zac Medico wrote:
> On 09/27/2012 12:53 PM, Brian Harring wrote:
>> Bullshit. This is optional in the sense of embrace/extend
>> 'optional'; if one PM takes up the new functionality, all have to
>> switch to writing unfinalized deps to the VDB, and all have to
>> switch to transfering that IUSE_RUNTIME crap to the VDB.
>
> I think the proposal suddenly becomes a lot saner if it's done as
> an EAPI extension, the optional runtime deps and IUSE_RUNTIME
> conditionals are isolated in a new separate variable (perhaps
> SRDEPEND), and IUSE_RUNTIME is not allowed to intersect with IUSE.
> Using a separate SRDEPEND variable means that the package manager
> only has to preserve USE conditionals in the vdb for that one
> variable.


Saner, perhaps, but that would also mean the feature would be more or
less independent of the current USE handling within the PM.

Mind you if it's easier to deal with in the PM then I guess
piggy-backing on the current USE implementation isn't an advantage.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBkt0oACgkQ2ugaI38ACPAKtQEAgkIJJfyBV2 0VsKVL8/dPlKF9
B4+SnJGlA+daYTCjXvgA/jq7aNzN8Cuj/sE+S+VWCK5U50vtHX3CqhoeOitgf9Zl
=G5Tc
-----END PGP SIGNATURE-----
 
Old 09-27-2012, 08:52 PM
Zac Medico
 
Default Addressing GLEP-62 itself

On 09/27/2012 01:30 PM, Ian Stakenvicius wrote:
> On 27/09/12 04:13 PM, Zac Medico wrote:
>> On 09/27/2012 12:53 PM, Brian Harring wrote:
>>> Bullshit. This is optional in the sense of embrace/extend
>>> 'optional'; if one PM takes up the new functionality, all have to
>>> switch to writing unfinalized deps to the VDB, and all have to
>>> switch to transfering that IUSE_RUNTIME crap to the VDB.
>
>> I think the proposal suddenly becomes a lot saner if it's done as
>> an EAPI extension, the optional runtime deps and IUSE_RUNTIME
>> conditionals are isolated in a new separate variable (perhaps
>> SRDEPEND), and IUSE_RUNTIME is not allowed to intersect with IUSE.
>> Using a separate SRDEPEND variable means that the package manager
>> only has to preserve USE conditionals in the vdb for that one
>> variable.
>
>
> Saner, perhaps, but that would also mean the feature would be more or
> less independent of the current USE handling within the PM.

Well, the package manager could still treat IUSE_RUNTIME flags as valid
flags for things like USE deps in _other_ packages. So, they don't have
to be entirely independent. The idea is just to limit the scope where
those flags are allowed the package that declares the flags as runtime
flags, so that those runtime flags are only allowed in SRDEPEND.

> Mind you if it's easier to deal with in the PM then I guess
> piggy-backing on the current USE implementation isn't an advantage.

Part of my concern is not just the implementation details, but also
being able to explain/document for communication purposes. If it's such
a mess that it's difficult to communicate, then it sucks for everyone
involved.
--
Thanks,
Zac
 
Old 09-29-2012, 09:55 AM
Michał Górny
 
Default Addressing GLEP-62 itself

On Wed, 26 Sep 2012 03:29:17 -0700
Brian Harring <ferringb@gmail.com> wrote:

> On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote:
> > On Tue, 25 Sep 2012 12:54:39 -0700
> > Brian Harring <ferringb@gmail.com> wrote:
> >
> > > On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote:
> > > > On Tue, 25 Sep 2012 14:47:33 -0400
> > > > Ian Stakenvicius <axs@gentoo.org> wrote:
> > > >
> > > > > Based on the above I do expect the reference implementation would also
> > > > > need to change. I expect, for instance, that the PM's
> > > > > metadata-handling would need to occur as normal even though none of
> > > > > the package's phase functions would run, that is, *DEPEND
> > > > > (realistically RDEPEND as that should be the only one affected here,
> > > > > maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage
> > > > > would not be re-emerging the package from the tree the original ebuild
> > > > > would remain.
> > > >
> > > > Yes, unless I'm missing something that's the intent. I will re-read
> > > > and update the GLEP a bit sometime this week.
> > >
> > > There's a fairly strong user interaction component here, along w/
> > > potential nastyness for ebuilds (the proposal assume that a flag will
> > > be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I
> > > guarantee instances where that fails can be found in the tree if a
> > > basic audit was done). Additionally, this *is* useless if it's done
> > > in a form the UI an't display/handle; Ciaran may bitch about
> > > REQUIRED_USE's UI (which I knew going in was going to be
> > > problematic, just to be clear), but he's right on that front.
>
> ^^^ This point still needs addressing.

What kind of addressing? The user interaction works like usual --
portage lists a bunch of flags, some of them may have additional
hammers or sickles to mean that they will not trigger the rebuild.
Nothing more is required.

What is even more important, there is nothing new to learn
for the user. In fact, he doesn't need anything new from UI. He will
just set the flag like he did 10 years ago.

> > > Additionally, this needs to be thought out how it'll interact with
> > > eclasses; what stacking, etc. It doesn't cover the basics there to
> > > say the least.
> >
> > The proposal didn't cover eclasses at all. Is there a need to do so or
> > are we chasing some kind of perfection based on filling all unused
> > slots?
>
> Eclass stacking here matters; if it's stacked, it means ebuilds have
> to use out of bound (ie, other vars) to tell the eclass when it
> shouldn't mark a flag as runtime toggable. If it's not stacked by
> the pm, then they have to manually stack; that differs from the norm
> and makes it easier to screwup; however; does allow for them to
> filter, albeit a slight pain in the ass doing so.
>
> There's a choice there, and the answer matters, so yes, you should
> actually have a complete glep before trying to shove it up to the
> council and extract a vote out of them. Lest the intention is to just
> have them kick it back to the curb...

As others have said, we're not stacking it. Using it in eclasses
is whacky and should be avoided. End of the story.

> > > Pretty much, this needs an implementation, partial conversion of the
> > > tree to demonstrate it.
> > >
> > > Just to prove that fricking point; if you had tried implementing this,
> > > a full investigation of what's involved alone, you'd have spotted that
> > > the core of the proposal is based on a wrong assumption.
> > >
> > > Portage doesn't write unfinalized DEPEND/RDEPEND/PDEPEND to the VDB.
> >
> > There's a footnote there, saying:
> >
> > The package manager has to ensure that all relevant information is
> > stored in the installed package metadata.
>
> Frankly I don't fully buy that you were aware of this issue from the
> start of the proposal; the wording partially covers it however.
> Ddoesn't call it out, but via tha req it dumps it on the package
> manager developers heads to sort it- which already is the case.
> Binpkgs minimally weren't addressed which is why I still don't think
> this was actually spotted up front.

We talked about it, don't you remember? That's why I have updated
the spec and put the whole implementation details thing with special
note what needs to be stored in metadata.

--
Best regards,
Michał Górny
 
Old 09-30-2012, 09:15 PM
Brian Harring
 
Default Addressing GLEP-62 itself

On Sat, Sep 29, 2012 at 11:55:22AM +0200, Micha?? G??rny wrote:
> On Wed, 26 Sep 2012 03:29:17 -0700
> Brian Harring <ferringb@gmail.com> wrote:
>
> > On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote:
> > > On Tue, 25 Sep 2012 12:54:39 -0700
> > > Brian Harring <ferringb@gmail.com> wrote:
> > >
> > > > On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote:
> > > > > On Tue, 25 Sep 2012 14:47:33 -0400
> > > > > Ian Stakenvicius <axs@gentoo.org> wrote:
> > > > >
> > > > > > Based on the above I do expect the reference implementation would also
> > > > > > need to change. I expect, for instance, that the PM's
> > > > > > metadata-handling would need to occur as normal even though none of
> > > > > > the package's phase functions would run, that is, *DEPEND
> > > > > > (realistically RDEPEND as that should be the only one affected here,
> > > > > > maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage
> > > > > > would not be re-emerging the package from the tree the original ebuild
> > > > > > would remain.
> > > > >
> > > > > Yes, unless I'm missing something that's the intent. I will re-read
> > > > > and update the GLEP a bit sometime this week.
> > > >
> > > > There's a fairly strong user interaction component here, along w/
> > > > potential nastyness for ebuilds (the proposal assume that a flag will
> > > > be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I
> > > > guarantee instances where that fails can be found in the tree if a
> > > > basic audit was done). Additionally, this *is* useless if it's done
> > > > in a form the UI an't display/handle; Ciaran may bitch about
> > > > REQUIRED_USE's UI (which I knew going in was going to be
> > > > problematic, just to be clear), but he's right on that front.
> >
> > ^^^ This point still needs addressing.
>
> What kind of addressing? The user interaction works like usual --
> portage lists a bunch of flags, some of them may have additional
> hammers or sickles to mean that they will not trigger the rebuild.
> Nothing more is required.
>
> What is even more important, there is nothing new to learn
> for the user. In fact, he doesn't need anything new from UI. He will
> just set the flag like he did 10 years ago.

1) REQUIRED_USE interaction. That's a rats nest, trust me on that
one. If your proposal is to just to have people tweak, get yelled at
by the pm, tweak, etc, well, on behalf of users, thanks a lot.

2) While hard to comment since your 'updated' glep wasn't fully
updated- now is self inconsistent (minimally, trace backwards
compatibility; fix it in full next time)... you're not exactly
covering how this will go; best I can figure, you just want to shove
yet another coloring (great for color blind people) or syntax markup
on emerge -pv style output, somehow indicating runtime toggable or
not; this is getting picked at because that display already is a
crapfest and overloaded.

3) You're ignoring cycles here; specifically suggested dep based
cycles that influence the originating node, and how that is
represented- this isn't counting representing during --tree mode what
is brought in where/when because of it.

4) Finally, and more damningly, you're ignoring apps like porthole.
You need to think long/hard about how *exactly* porthole is going to
indicate to users what optionals are there- more importantly, what
those optionals induce/require (that's where it truly gets ugly and
your lack of dep resolver knowledge, and unwillingness to do a patch
and learn the basics there become infuriating); || () or blockers w/in
suggested alone are going to make things painful.


> > > > Additionally, this needs to be thought out how it'll interact with
> > > > eclasses; what stacking, etc. It doesn't cover the basics there to
> > > > say the least.
> > >
> > > The proposal didn't cover eclasses at all. Is there a need to do so or
> > > are we chasing some kind of perfection based on filling all unused
> > > slots?
> >
> > Eclass stacking here matters; if it's stacked, it means ebuilds have
> > to use out of bound (ie, other vars) to tell the eclass when it
> > shouldn't mark a flag as runtime toggable. If it's not stacked by
> > the pm, then they have to manually stack; that differs from the norm
> > and makes it easier to screwup; however; does allow for them to
> > filter, albeit a slight pain in the ass doing so.
> >
> > There's a choice there, and the answer matters, so yes, you should
> > actually have a complete glep before trying to shove it up to the
> > council and extract a vote out of them. Lest the intention is to just
> > have them kick it back to the curb...
>
> As others have said, we're not stacking it. Using it in eclasses
> is whacky and should be avoided. End of the story.

It's your proposal there boss. That's a stupid decision, but as said,
your proposal to run into the ground if you'd like.

However. I suggest you actually document that in your proposal that
it breaks from the stacking norm. Also, drop the backwards
compatibility claim at the bottom.

It was bullshit before, the fact I keep having to picking at this
means I'm going to start doing so in creative ways; thus I'll just
quote an exchange from 'the carnival'- it's "pure beeship, beeship,
not true, false, Beeship!" "oh... bullshit" "Oui!". Quote wasn't a
perfect fit, but I'm getting tired of having to use the plain
'bullshit' response for your emails.


> > > > Pretty much, this needs an implementation, partial conversion of the
> > > > tree to demonstrate it.
> > > >
> > > > Just to prove that fricking point; if you had tried implementing this,
> > > > a full investigation of what's involved alone, you'd have spotted that
> > > > the core of the proposal is based on a wrong assumption.
> > > >
> > > > Portage doesn't write unfinalized DEPEND/RDEPEND/PDEPEND to the VDB.
> > >
> > > There's a footnote there, saying:
> > >
> > > The package manager has to ensure that all relevant information is
> > > stored in the installed package metadata.
> >
> > Frankly I don't fully buy that you were aware of this issue from the
> > start of the proposal; the wording partially covers it however.
> > Ddoesn't call it out, but via tha req it dumps it on the package
> > manager developers heads to sort it- which already is the case.
> > Binpkgs minimally weren't addressed which is why I still don't think
> > this was actually spotted up front.
>
> We talked about it, don't you remember?

Think you're being cracky there; the point I made there was that your
proposal didn't address the need for unfinalized across all bulit
deps- there was no discussion about that.


> That's why I have updated
> the spec and put the whole implementation details thing with special
> note what needs to be stored in metadata.

Not going to give you an inch on this shit anymore; Gleps are derived
from PEPs; standard to include the cons of a proposal, in this case
you actually need to quantify/document the perf hit (portage in
particular) in there.

As for "updated to cover it"... meh. I read that section; you're
requirements of the PM imply we can always extract out the relevant
bits from the original source trees.

Simple example,
encode? ( || ( x? ( blah ) y:=* ) )

with x being an IUSE_RUNTIME toggle. Try extracting that. It's a
PITFA; partial rendering of all non IUSE_RUNTIME for the full tree,
storing that tree in full, is what's required- that example
demonstrates why thinking "just extract the parts" is cracked out
(bluntly: moreso naive, as ciaran said, if you dick around w/ this
level of the managers code, you're going to find that sort of thing
intractable because of the rules of the syntax).


Finally, going to fold in a snippet from ciaran/you in a separate
branch of this thread:

On Sat, Sep 29, 2012 at 08:43:14PM +0200, Micha?? G??rny wrote:
> On Sat, 29 Sep 2012 17:13:14 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > You've also still not provided any kind of reference implementation,
> > and your "reference implementation" section is still written with a
> > complete lack of awareness of how dependency resolution is actually
> > done.
>
> I'm sorry I haven't got time yet to write a package manager. I promise
> I will do it as soon as I have time to do so. Thank you for your
> patience.

Good news!

You don't have to write a PM from scratch- just modify portage to
prototype it. We realize how annoying it is to have your time wasted,
thus a patch is enough. Enjoy!


1) Don't be a tool. Also, if you want to write a PM, I suggest you do
so- the timbre of your proposals would likely shift towards sanity (or
at least things would be quieter while you're off having at it with a
windmill).
2) PMS requires portage support exist before a patch goes in; you've
got to do that anyways if you actually think this is going anywhere.
3) The things the PM authors are beating you over the head with all
map back to realities at the implementation level; if you'd get off
your ass and do it rather than arguing, you'd be getting further with
your proposal (or find it nonviable, and do a different proposal).


Honestly, your proposal doesn't feel like "optional deps"; it feels
like you're just trying to shove in an efficiency hack to avoid
rebuilds in certain cases, rather than designing a system for exposing
suggested deps to people. Efficiency hack doesn't involve a heavy
UI angle, optiional/suggested deps do.

Either way, I'm done w/ this proposal; you come up w/ a prototype,
I'll look, till then this is a waste of time.

Should the council/folk care, consider that a strong -1 on my part.
~harring
 

Thread Tools




All times are GMT. The time now is 11:46 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org