On Tue, 16 May 2006 12:55:11 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: | > That's not really true. Relying upon "anything that Portage | > handles", including relying upon Portage bugs and internals, leads | > to broken ebuilds when said things change. | | ...which is why the ebuild env for portage is extremely carefully | maintained- mistakes may occur, but willy nilly changes don't. | Regardless, at least for gentoo it still however *is* the standard | for ebuilds, breaking the 'standard' out of portage is fine, changing | intrinsic parts of the standard isn't.
What standard? | > You're acting like Paludis is dropping something huge here. Not | > emulating a few weird PORTAGE_ variables that nothing uses is not | > breaking eapi. If ebuilds genuinely rely upon something, we emulate | > as necessary. | | Then I'll state it again; you're changing the core environment | handling via intentionally dropping all local vars defined per phase | run. Yes, we're intentionally not emulating a Portage misfeature and will carry on not doing so until we come across a genuine case where this causes breakage that isn't better fixed by other means. We haven't said we definitely won't hack Paludis to make local variables not actually local the way Portage does. Equally, we're not going to make that change unless there's a damned good reason to do so. | Add binpkgs, and try it- you'll get some fun behaviour there. As we're not emulating Portage's binary package format, it's not an issue at all. | > *shrug* Your perception on this one's probably skewed if (as it | > seems) you've been focusing on the trivial and easily replaceable | > bash part, rather than the interesting things which are done in C++. | | The bash part is all that matters, hence why I'm focusing on it- as | you stated above, the data (ebuilds) handling is what matters. A lot of the ebuild handling (especially environment) is done in C++. You're missing all kinds of things by only looking at the bash code. | > There is a difference between "changes that affect people not using | > the newer package manager" and "changes that are only relevant to | > people using the newer package manager". Anyone asking for features | > that will lead to Portage breaking will be beaten with a spork. | | N profile inheritance breaks portage. | You were saying? N profile inheritance does not break Portage unless someone mis-sets their profile. Plenty of changes have been made that would trigger the same class of breakage were the user to mis-set their profile. We are not asking for N inheritance in profiles that will be used by Portage. | Feel free to suggest them- since it's initial discussion, your | comments on it haven't really progressed beyond "y'all did it badly", | without naming a solution that works. I gave you two that worked. One, the .ebuild.n thing, which avoids the filename incompatibility issue and the source issue. Two, the "eapi as a function" thing, which avoids the source issue. | > Had you read the source or the documentation, you'd know fine well | > that we support eclass unified overlays. I really think you should | > refrain from making those kinds of claims until you actually have | > the slightest clue what you're talking about. | | Offhand, you're ignoring the point about lack of translation script | for vdb, and that paludis requires a new install. Doesn't actually require it. It's just a good idea to do so, and we're not going to support people who don't *at this stage*. | Re: eclass, had to dig in the src for that one, doc's don't cover | it. Sure they do. It's included as part of the bootstrap howto doc. | Your repositories support specifying an arbitrary eclass- they do | not support the standard unification on the fly of eclass that most | portage users use- *technically* it can be done via copying eclasses | from each repo into an eclass directory (better yet symlinks), but | that's not unifying- that's working around the implementation. Which is a good thing. Rather than emulating one of Portage's sillier misfeatures, which only came about because of the whole "single repository" concept being hard-coded, we did it properly. | > Huh? Profiles that some Portage versions can't use have been added | > plenty of times previously. | | Yep, and we still get bugs about .50- that doesn't mean it's right | (just because someone else did something stupid doesn't mean you | can). It's pretty simple, don't stick stuff into the tree that can | silently fail, stick stuff in that is detected instead of silent | failures. It won't be a silent failure. | > | Point is, the tree (you're own words) is not a playground, nor is | > | it a demoscene- don't introduce the potential for screwup in the | > | tree without a damn good reason. | > | > That argument is like claiming that adding an amd64 profile to the | > tree is a potential screwup because x86 users might use it. | | x86 users could at *least* render the profile out properly. All | gentoo users sans the few paludis experimenters cannot use N profile | inheritance, and portage will misbehave with it. Wrong profile is | pretty damn obvious (compilation failure)- partially loaded profile | is a bit different however, you only get part of the profile tree | loaded (likely enough to continue on), but not all of it's settings. No no, it can be made to explode as noisily as we like. | Bit retarded here, but seriously, work it out in the overlay (like | most herds do), then try to bring it to the tree. Oh, we already went through that stage. | > | Bluntly, you break compatibility with vdb/tree, paludis has no | > | real future with gentoo beyond forking- requiring 100,000 users | > | to reinstall because you don't want to do backwards compatibility | > | is daft. | > | > A reinstall isn't needed at all. | | Currently is, going by your docs (and last look through code)- url? Isn't going to be documented, because I don't want people doing that just now. | > Paludis is no more incompatible with ebuilds than any new Portage | > release is. | | Rhetoric. I've pointed out specific changes you've gone and done | that render it incompatible, and the response is "portage does it | worse"? Portage doesn't willy nilly convert/drop vars, nor screw with | the env handling. Not emulating Portage bugs isn't an incompatibility. | That and the thread is getting fairly wide in discusion, rather then | the profile specific "does alt pkg manager X cruft belong in the | tree?" Well yes, because rather than discussing the issues, you're trying to turn this into your personal crusade against Paludis. -- Ciaran McCreesh Mail : ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
