Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies

[Brian Harring]

On Sun, Sep 16, 2012 at 01:21:26PM +0200, Micha?? G??rny wrote:
> On Sun, 16 Sep 2012 04:10:01 -0700
> Brian Harring <ferringb@×××××.com> wrote:
>
> > On Sun, Sep 16, 2012 at 09:56:27AM +0200, Micha?? G??rny wrote:
> > > But consider that for example Zac & AxS (correct me if I recall it
> > > correctly) considered making changing the meaning of RDEPEND to
> > > install them before the build, thus effectively making 'build,run'
> > > useless.
> >
> > I really am not trying to be a blatant dick to you, but this has
> > /zero/ relevance.  RDEPEND means "required for runtime".  That ain't
> > changing.  If they were discussing changing what RDEPEND meant, then
> > they were high, period.
> >
> > If zac/axs want to try and make the resolver install RDEPEND before
> > DEPEND... well, they're free to.  That doesn't change the fact that
> > the deps still must be specified correctly; in short, build,run is
> > very much relevant.
>
> I don't think we have made up our mind what *exactly* we want from
> deps.

Are we now expecting deps to give us ponies or something?  We know 
*exactly* what we want from deps, and their current definition- the 
problem isn't the definition, it's that we don't have the forms we 
need.


> Just because we have something semi-correct right now, doesn't
> mean that we don't want to change that.

This is a no-op argument against the proposal: "we can't 
change the deps because we might want to change the deps".  It's also 
irrelevant due to the core basis of it being broken as fuck (described 
above).


> > There's also the fact doing this means best case, 2 less inodes per
> > VDB entry (more once we start adding dependency types).  For my vdb,
> > I have 15523 across 798 pkgs.  1331 of that is *DEPEND, converted to
> > DEPENDENCIES the file count is 748.  Note that's preserving DEPEND,
> > although it's worthless at this stage of the vdb.  So 5% reduction in
> > files in there.  Whoopy-de-doo, right?
>
> So we can modify vdb now? What about all those applications which
> obviously are broken due to that?

You're misunderstanding the problem of the VDB.  We cannot change the 
core structure of it- certain ebuilds currently expect to be able to 
find USE/IUSE at specific pathways.  That's where we're blocked.

Adding a new metadata key can, and has been done (defined_phases, 
properties, required_use, etc).  Removing keys can be done.  For 
efficiency, not writing a key if it's empty, can be and is being done.

Basically, your retort again, is wildly off mark and misunderstanding 
the problem.

I strongly suggest you go do some real research into the existing 
PMs, and the problems being discussed.  Go read some code; you've 
minimally got 3 different codebases to work from, and that's not 
counting ML archives, tools, PMS, or the devmanul.

If per you're statements, you're actually serious about writing your 
own PM, you're going to need to know this sort of shit /anyways/ to 
actually do the basic legwork of a PM, so please go do the necessary 
legwork if you want to persist in arguing about internals.

~harring