[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
From:       Kent Fredric <kentfredric () gmail ! com>
Date:       2013-09-30 21:40:37
Message-ID: CAATnKFB9XEA8Zyv5Tz0iidsJqnqCHarXJ1ux4QwU+GiGVPbQ4Q () mail ! gmail ! com
[Download RAW message or body]

On 1 October 2013 04:52, Martin Vaeth <vaeth@mathematik.uni-wuerzburg.de>wrote:

>
> For instance, if you have your home-brewn version of program X,
> you can just install the version under its own package name Y and
> make it satisfy all dependencies of X.
> (Currently you have to mess around with package.provided which has
> many drawbacks like e.g. problems with USE-dependencies and,
> moreover, you cannot publish Y in an overlay without requiring
> that the user of that overlay modifies his package.provided manually.)


Here, this is even more annoying, because as long as this inverse
dependency is regulated by the eclass, even ebuilds in alternative trees
are out of luck from being seen as candidates for an multi-way provided
dependency, at least, you'd have to modify the eclass "somehow"

This is something a native PROVIDES= implementation is not limited by.

Though I reapeat, I do not want PROVIDES="perl-core/Foo-Bar", because thats
going to have us the same problem, as it declares provides only on the
granularity of *packages* not the granulatiry of files/modules.

I'd be championing something more like ( but not nessecarily exactly like )

PROVIDES="cpan-module://Module::Build/4.5"

Borrowing terms from the metadata.xml information, and the use of a
per-token-type protocol prefix allows for multiple unambiguous namespaces
that are not bound to the cat/package layout.

And here, the semantics after "://" could be implemented differently if
nessecary.

Consuming code would just say

DEPEND="cpan-module://Module::Build" or
DEPEND=">=cpan-module://Module::Build/4.0"

Though I don't know. The real problem is that as convenient as a PROVIDES=
interface may be, doing it performantly could be a nightmare, and portage
would probably need some sort of PROVIDES cache to even support such a
feature efficiently. ( Which is basically what my solution offers, just
with a developer-side-cache-generation instead of user-side-caching )

-- 
Kent

[Attachment #3 (text/html)]

<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 1 October \
2013 04:52, Martin Vaeth <span dir="ltr">&lt;<a \
href="mailto:vaeth@mathematik.uni-wuerzburg.de" \
target="_blank">vaeth@mathematik.uni-wuerzburg.de</a>&gt;</span> wrote:<br> \
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><br> For instance, if you have your home-brewn \
version of program X,<br> you can just install the version under its own package name \
Y and<br> make it satisfy all dependencies of X.<br>
(Currently you have to mess around with package.provided which has<br>
many drawbacks like e.g. problems with USE-dependencies and,<br>
moreover, you cannot publish Y in an overlay without requiring<br>
that the user of that overlay modifies his package.provided \
manually.)</blockquote></div><br></div><div class="gmail_extra">Here, this is even \
more annoying, because as long as this inverse dependency is regulated by the eclass, \
even ebuilds in alternative trees are out of luck from being seen as candidates for \
an multi-way provided dependency, at least, you&#39;d have to modify the eclass \
&quot;somehow&quot;<br> <br></div><div class="gmail_extra">This is something a native \
PROVIDES= implementation is not limited by.<br><br></div><div \
class="gmail_extra">Though I reapeat, I do not want \
PROVIDES=&quot;perl-core/Foo-Bar&quot;, because thats going to have us the same \
problem, as it declares provides only on the granularity of *packages* not the \
granulatiry of files/modules.<br> <br></div><div class="gmail_extra">I&#39;d be \
championing something more like ( but not nessecarily exactly like \
)<br><br></div><div class="gmail_extra">PROVIDES=&quot;cpan-module://Module::Build/4.5&quot;<br><br></div><div \
class="gmail_extra"> Borrowing terms from the metadata.xml information, and the use \
of a per-token-type protocol prefix allows for multiple unambiguous namespaces that \
are not bound to the cat/package layout. <br><br></div><div class="gmail_extra"> And \
here, the semantics after &quot;://&quot; could be implemented differently if \
nessecary.<br><br></div><div class="gmail_extra">Consuming code would just say \
<br><br></div><div class="gmail_extra">DEPEND=&quot;cpan-module://Module::Build&quot; \
or DEPEND=&quot;&gt;=cpan-module://Module::Build/4.0&quot;<br> <br></div><div \
class="gmail_extra">Though I don&#39;t know. The real problem is that as convenient \
as a PROVIDES= interface may be, doing it performantly could be a nightmare, and \
portage would probably need some sort of PROVIDES cache to even support such a \
feature efficiently. ( Which is basically what my solution offers, just with a \
developer-side-cache-generation instead of user-side-caching )<br> </div><div \
class="gmail_extra"><br>-- <br>Kent<br> </div></div>



[prev in list] [next in list] [prev in thread] [next in thread]