Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

On Tue, May 16, 2006 at 07:07:05PM +0100, Ciaran McCreesh wrote:
> On Tue, 16 May 2006 10:33:56 -0700 Brian Harring <ferringb@×××××.com>
> 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.

...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.


> | 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.

Then I'll state it again; you're changing the core environment 
handling via intentionally dropping all local vars defined per phase 
run.  Add binpkgs, and try it- you'll get some fun behaviour there.


> 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++.

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.  

Stating that the bash concerns are trivial while the C++ side can be 
interesting is ignoring the point, the bash bits must match- I don't 
care if it's C++ or python or haskell for the high level, the ebuild 
env support must *not* induce any intentional changes that break 
ebuilds.


> 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.

use/useq change over occured well after the tree had been converted- 
it's actually a decent example of how to do the changeover- that was 
also a permenant change, not a "paludis is an alternative and we want 
to stick it in the tree".


> | 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.

N profile inheritance breaks portage.
You were saying?

Yes it's needed (regardless of the manager), but the point was "don't 
expose users to sharp/pointy things without a good reason".


> | 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.

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.

EAPI has it's faults, but it *does* version the ebuild format 
(regardless of the tree format) to move forward, which was it's 
intention.  Versioning the tree format is a related, but seperate 
issue.


> | 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.

Offhand, you're ignoring the point about lack of translation script 
for vdb, and that paludis requires a new install.

Re: eclass, had to dig in the src for that one, doc's don't cover it.  
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.

Simple example, eclasses in overlay X must override PORTDIR y, no 
eclass in X, check Y.

If paludis supports that common usage model, kindly point it out 
since I've yet to spot support in the code for it.


> | > 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.

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.


> | 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.

look in the files directory- specifically modifies extmaker to be 
PORTAGE_TMPDIR aware to fix a security bug.


> | 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.

Bit retarded here, but seriously, work it out in the overlay (like 
most herds do), then try to bring it to the tree.


> | 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?


> | 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.

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.

Env handling *is* a bitch to get it properly- the ebd based 
portage-2.1 already demonstrated it, and all that was doing was 
*fixing* the statefullness of the env, not hacking all local data out.

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?"
~brian