On Tue, 16 May 2006 10:33:56 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: | > What eapi=0 standard? We emulate Portage internals where it's found | > to be necessary, and don't otherwise. | | eapi=0 is what 2.1/2.05x supports.
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. | Features are fine, but for gentoo backwards compatibility *is* a | concern, as such dropping the bits that you dislike (but existing | ebuilds rely on) is a no go. 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. | > | Mind you that's from a quick read through | > | of your ebuild env reimplementation, stated the issues already | > | and they still remain- incomplete support for the standard is one | > | thing, changing it is another (y'all are doing the latter). | > | > What standard? Are you trying to say that Paludis should emulate | > Portage's bugs, because the standard is "exactly what Portage does"? | | See above. Paludis (my view) is a rewrite of portage, rather then a | reimplementation- as you've stated, dropping the stuff that you deem | misfeatures. A 'rewrite' implies that we're starting from "what Portage does", and making something that does the same thing in the same way. That's not how it's being done. We're looking at it a) from what ebuilds do, and b) from what the program is expected to do, and then filling in the middle. The only part that's really at all close to Portage is the bash stuff for ebuilds, and that's pretty much necessary because of the ebuild <-> package manager interface thing. *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++. | This is fine, but portage *is* what gentoo is based uses now, and | what all ebuilds have been written to, as such you need to either | support the misfeatures or have a bullet proof transition plan to | deal with the things you decided to carve out. Which, funnily enough, is what we do. | This is directly relevant because you now want to modify the | gentoo-x86 repo to standards gentoo does not actually support. Call | it "dropping the misfeatures", but it's the reality of backwards | compatibility (something that has been kicking portage devs in the | nuts for years now). Again, not really true. Said Portage devs have pushed through far larger changes than anything we need -- look at the "use becoming useq" behaviour changes, for example. Paludis does not require or want any such large change, and we'd consider anything that required that to be broken. | Feature introduction is done via introducing support, then sitting on | it for ~6 months to ensure folks don't get bit by it- notable | exception was virtuals/* metapkg, although the buttload of bugs from | it is a demonstration of *why* this route must be taken. 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. | This is also why eapi came about- faster introduction of | compatibility breaking changes. Which, unfortunately, it doesn't really do, since ebuilds still have to be filename and source compatible. There were far better ways this could have been handled. | Meanwhile, the precedent for changes to the tree (pkg manager related | changes) is that of "don't break shit for users", introducing N | parent inherit profiles into the tree still qualifies as a concern- | as stated, you're after demoing capabilities, do it somewhere other | then production data. N parent inherit profiles don't break anything for users who don't use said profiles. Any user switching to an unsuitable profile, N parent or not, will end up with a h0rked system. The same occurs when new profiles requiring newer Portage versions are introduced, and that's been done several times. | Snarky response aside, I read the src (note the env screwups I've | pointed out, and the fact y'all don't support try eclass unified | overlays), and your documentation- the point was that paludis can | only be used for new installs, and you're locked to paludis as your | pkg manager at that point without a translation script. 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. | Trying to make it clear that paludis isn't something you try out for | a bit, then revert back to portage- it's a full rebuild. That | seriously limits the usefulness of the requested profile. Sure. Which is why it's a profile scope thing, the same as, say, multilib. | Just because something is a viable alternative to portage doesn't | mean the tree should be mutated to the alternative Adding a subprofile is not mutating the tree. Get a sense of perspective here. We're not asking everyone to change how they invoke the 'use' function... | Yes, paludis is a viable pkg manager- it's not viable to work with | ebuilds written to portage (eapi=0) however Sure it is. | One thing I am curious about though, is how closely you've checked | things are running properly- ebuilds have preserved their state in | local vars saved in the env dump for well over 2 years, cutting that | out on a whim for 22k ebuilds is kind of risky. It'll show at | unmerge time and for binpkgs... Funnily enough, we know what we're doing. | > Uh, a user changing to any incorrect profile will screw up their | > system. Ever tried using an amd64 profile on x86? | | We can't do anything about that idiocy. | | That doesn't mean a profile should be added to the tree that portage | is incapable of resolving properly however- simple example would be | inheriting from two parents, one that's base arch agnostic defaults, | other is arch specific modifications. Huh? Profiles that some Portage versions can't use have been added plenty of times previously. | > | eapi incompatibility | > | > You mean "not emulating some of Portage's sillier bugs that very few | > things rely upon anyway", right? | | See above. Renaming of PORTAGE_* -> PALUDIS_* vars doesn't strike me | as "sillier bugs", strikes me as "we stamped it with our name, thus | introducing subtle bugs into minor packages like perl". We emulate some PORTAGE_ variables. We don't emulate the ones that aren't necessary. | And yes, that's actually a valid example- easy to spot via just a | simple grepping of the tree (I suggest you do so). Heh. You lose. It isn't. | 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. | 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. | The original discussion was about adding a paludis profile (not | "portage sucks"), getting back to it, paludis is incompatible with | portage at the actual ebuild level- considering that, why should the | tree be modified to add a profile that's just going to introduce | further breakage? Paludis is no more incompatible with ebuilds than any new Portage release is. -- Ciaran McCreesh Mail : ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
