Kent Fredric kentfred...@gmail.com wrote:
The best solution I presently have for this problem, would be to have
a PROVIDES-${PV}.json file in every package under files/
Not under files but in the eclass, and the rest of the
work is done by the perl-dep function.
The reason I suggested
On 1 October 2013 04:52, Martin Vaeth va...@mathematik.uni-wuerzburg.dewrote:
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
On 29 September 2013 11:13, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
The best solution I presently have for this problem, would be to have
a PROVIDES-${PV}.json file in every package under files/
Not under files but in the eclass, and the rest of the
work is done by the
Matt Turner matts...@gentoo.org wrote:
|| ( =dev-lang/perl-5.14 virtual/perl-Term-ANSIColor )
and possibly change this if perl-5.20 does no longer contain
perl-Term-ANSIColor.
Isn't that exactly what the virtual should do?
One can discuss what it *should* do, but it is certainly not
what
Kent Fredric kentfred...@gmail.com wrote:
you'll still need logic like || (
dev-lang/perl[perl_module_Term_ANSIColor(-)] perl-core/Term-ANSIColor )
to just deal with the reality of what upstream are asking for.
My point is that the perl ebuild need not necessarily follow upstream:
It
Kent Fredric kentfred...@gmail.com wrote:
I mean, the reason virtuals suck is predominantly the fact we have to
update the conditionals to accurately reflect the version on the virtual
Concerning the eclass idea which was already mentioned and
which is perhaps even better than my suggeestion
On 28 September 2013 22:31, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
Note that it would be stupid to depend on e.g.
=virtual/perl-Term-ANSIColor-4.02
for several reason:
1. The virtual does not even exist :)
Nope, it does. Its just called =virtual/perl-Term-ANSIColor-4.20.0 ,
On 28 September 2013 22:46, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
Kent Fredric kentfred...@gmail.com wrote:
you'll still need logic like || (
dev-lang/perl[perl_module_Term_ANSIColor(-)] perl-core/Term-ANSIColor
)
to just deal with the reality of what upstream are
On Sun, 29 Sep 2013 08:47:52 +1300
Kent Fredric kentfred...@gmail.com wrote:
For that, a slot-dict approach is far more sane.
The only reason anyone can make that claim is that no-one really knows
what slot dictionaries are or how they'd work in practice. Until
there's a rough description of how
On 28 September 2013 23:36, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
Concerning the eclass idea which was already mentioned and
which is perhaps even better than my suggeestion from the
other posting, since it avoids some of the disadvantages:
by having an eclass that
On 29 September 2013 08:51, Ciaran McCreesh
ciaran.mccre...@googlemail.comwrote:
The only reason anyone can make that claim is that no-one really knows
what slot dictionaries are or how they'd work in practice. Until
there's a rough description of how they work and a prototype
implementation,
On 29 September 2013 09:14, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
this dependency will install for a user with
unstable keywords
That, in itself, indicates the user is usually OK with new versions of
things ;)
corelist -a says virtual/perl-Digest-MD5-2.520.0 should || ( perl
Kent Fredric kentfred...@gmail.com wrote:
So are you basically suggesting that for dual life modules, we simply
ignore that they're dual-lifeable, and then when upstream splits a package
from core so that its no longer dual life, that we simply ignore that too,
and fake it still being core
Kent Fredric kentfred...@gmail.com wrote:
--001a11336248343a2604e7770011
Content-Type: text/plain; charset=UTF-8
On 28 September 2013 23:36, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
Concerning the eclass idea which was already mentioned and
which is perhaps even better than my
Kent Fredric kentfred...@gmail.com wrote:
this dependency will install for a user with unstable keywords
That, in itself, indicates the user is usually OK with new versions of
things ;)
You are intentionally confusing new version (AKA upgrade) with
_additional_ installation of a package,
On 27 September 2013 08:02, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
For those which are provided by perl itself, you could have
a corresponding useflag of dev-lang/perl and make a use dependency:
If the main perl tarball does not provide the package, the perl ebuild
can pull in
Sorry if this is duplicate: I repost since I cannot see it after
a few hours.
Kent Fredric kentfred...@gmail.com wrote:
On 27 September 2013 08:02, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
For those which are provided by perl itself, you could have
a corresponding useflag of
On Fri, Sep 27, 2013 at 12:48 PM, Martin Vaeth
va...@mathematik.uni-wuerzburg.de wrote:
I was not suggesting inlining the list into the dependency but
only inlining the USE-flag into the (single) perl ebuild.
Currently if I have a package which needs e.g. Term-ANSI-Color,
but not in a
On 28 September 2013 07:48, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
Sorry if this is duplicate: I repost since I cannot see it after
a few hours.
Kent Fredric kentfred...@gmail.com wrote:
On 27 September 2013 08:02, Martin Vaeth
va...@mathematik.uni-wuerzburg.dewrote:
On Thu, 26 Sep 2013 20:51:26 +1000
Michael Palimaka kensing...@gentoo.org wrote:
There isn't a 100% perfect solution currently, and I agree that
hurrying people will simply move us from not enough rebuilds to
too many rebuilds.
This is still a huge improvement.
--
Ciaran McCreesh
On 26/09/2013 20:55, Ciaran McCreesh wrote:
On Thu, 26 Sep 2013 20:51:26 +1000
Michael Palimaka kensing...@gentoo.org wrote:
There isn't a 100% perfect solution currently, and I agree that
hurrying people will simply move us from not enough rebuilds to
too many rebuilds.
This is still a huge
On Thu, 26 Sep 2013 21:14:11 +1000
Michael Palimaka kensing...@gentoo.org wrote:
On 26/09/2013 20:55, Ciaran McCreesh wrote:
On Thu, 26 Sep 2013 20:51:26 +1000
Michael Palimaka kensing...@gentoo.org wrote:
There isn't a 100% perfect solution currently, and I agree that
hurrying people
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/09/13 06:51 AM, Michael Palimaka wrote:
On 26/09/2013 17:53, Michał Górny wrote:
How do we handle packages which install multiple libraries? I'm
afraid forcing such a policy and/or hurrying developers to adapt
will only cause more of
On 27/09/2013 00:12, Ian Stakenvicius wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 26/09/13 06:51 AM, Michael Palimaka wrote:
On 26/09/2013 17:53, Michał Górny wrote:
How do we handle packages which install multiple libraries? I'm
afraid forcing such a policy and/or hurrying
Kent Fredric kentfred...@gmail.com wrote:
On 27 September 2013 05:57, Ciaran McCreesh
ciaran.mccre...@googlemail.comwrote:
virtual/perl-* is self-inflicted.
How would you recommend it?
For those which are provided by perl itself, you could have
a corresponding useflag of dev-lang/perl and
2013-09-26 17:04 Michael Palimaka napisał(a):
What about when the subslot of boost was equal to ${PV}? Was it really a
good idea to make everyone rebuild half their system for a bugfix
release, without even checking if the ABI changed?
It is wrong example due to 2 reasons:
1. Subslot of
26 matches
Mail list logo
