Re: [gentoo-dev] Paludis and Profiles

[Brian Harring]

On Wed, May 17, 2006 at 08:50:32PM +0100, Ciaran McCreesh wrote:
> On Wed, 17 May 2006 12:06:09 -0700 Brian Harring <ferringb@×××××.com>
> wrote:
> | Clarify on virtuals please.  Unless you're mangling the data for
> | sym/dir, that's an unmerge time decision (as such it's not vdb data
> | specific).
>
> We're faking new-style virtuals for old-style virtuals, so things end
> up in vdb that don't have an associated 'real' ebuild. Portage can't
> unmerge them, and it has some trouble with the reduced-content entries
> for these too.

Instead of on the fly generation of the virtuals pkgs (as 
pkgcore/portage do), you've flattened them into an actual on disk vdb 
entry?

Re: incompatibility, that can be dealt with by generating a fake 
ebuild- already generate an env from the looks of it (not seeing 
anything in RDEPEND/DEPEND however).


> | > We went over this already. Remember webapp.eclass?
> |
> | Nope.  Assume I'm stupid, don't ask a question when I ask for an
> | answer, just state it please- saves both you and I time.
> |
> | Do recall they were triggering merge -C calls on their own, but
> | that's not portage incompatibility as much as doing something dumb...
>
> And that's exactly it. At what point does something stop being API and
> start being "someone is doing illegal things with internals"?

Common sense.  Paludis wouldn't like what they were doing any more 
then pkgcore nor portage- modification of a node cannot cause unstated 
dependency changes, what they were doing was going outside the 
constant metadata rules binding all ebuild supporting pkg managers 
(well, the ones that don't want the 100-400x hit from lacking a 
metadata cache at least).

A real example of where portage doesn't support an ebuild in the 
tree would be welcome (as stated, if it exists it needs fixing).


> | Ebuild is easy- I'm pointing at it because the local env issue should
> | rear it's head there.  It's also a tool that ebuild devs rely on
> | fairly heavily for debugging, as such two birds one stone (locals
> | issue you get to investigate closer, and you flesh paludis out
> | further).
>
> Actually, I was planning to handle that one by BREAK_FUNCTIONS (name
> sucks and is not final), which is kinda like SKIP_FUNCTIONS but rather
> than skipping, launches an interactive shell.

Did something similar with ebuild-shell- folks for the most part liked 
it.

Meanwhile... get cracking, you'll see far more local assumptions 
transitioning between phases then transitioning between groupped merge 
phases -> groupped unmerge phases


> | > Portage still relies upon being able to source ebuilds, even if
> | > their EAPI isn't supported.
> |
> | Paludis doesn't?
>
> Nope. Paludis can sanely (as in, treat as EAPI masked) handle ebuilds
> that bash can't parse. This paves the way for XML-based ebuilds, which
> as we all know is a critical feature required for enterprise support.

'Cept EAPI was specifically targeted at bash based ebuilds only.  
Alternative formats (non bash fex), expected folks to solve that issue 
themselves (since I didn't see a sane general solution to it).

For what EAPI is defined as, portage supports it fully.


> | Related, doc this stuff out please.  Portage differences doc you've
> | got is more "we're better cause of xyz"- which is fine, but a low
> | level "this is what we do differently" (metadata/security fex) would
> | at least allow the possibility of folks being on the same page.
>
> Yeah, that's something that would be useful. I was trying to get spb to
> do it...

I'd suggest it as priority- it's really not all that fun arguging over 
details lifted from scanning the code, and getting into terminology 
wars.

Get the doc up, folks can evaluate what the actual support costs for 
paludis are vs assumptions/guesses.

~harring