On 1 October 2013 04:52, Martin Vaeth 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
Kent Fredric 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 that app
On 29 September 2013 11:13, Martin Vaeth
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
Kent Fredric 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, just because
Kent Fredric wrote:
> --001a11336248343a2604e7770011
> Content-Type: text/plain; charset=UTF-8
>
> On 28 September 2013 23:36, Martin Vaeth
>wrote:
>
>>
>> Concerning the eclass idea which was already mentioned and
>> which is perhaps even better than my suggeestion from the
>> other posting, sinc
Kent Fredric 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 for the forseeable
On 29 September 2013 09:14, Martin Vaeth
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" ;)
corelist -a says virtual/perl-Digest-MD5-2.520.0 should || ( perl v5.18 )
Though that virtual
On 29 September 2013 09:14, Martin Vaeth
wrote:
> the
> dependencies would not pull in unnecessary packages for the user.
>
Its just every time you say "unnessecary", that also implies that users **
NEVER** want new versions of dependencies.
That is just not true for most of the gentoo tree. If
Kent Fredric wrote:
>>
>> 1. The virtual does not even exist :)
>>
>
> Nope, it does. Its just called =virtual/perl-Term-ANSIColor-4.20.0
In this case the virtual is buggy, becaues it does not contain
|| ( dev-lang/perl-5.18* ... )
Due to this, this particular example is not so ideal: I wanted t
On 29 September 2013 08:51, Ciaran McCreesh
wrote:
> 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, "subslot dictionaries" is
On 28 September 2013 23:36, Martin Vaeth
wrote:
>
> 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 translates a special variable, say,
On Sun, 29 Sep 2013 08:47:52 +1300
Kent Fredric 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 they work and a prot
On 28 September 2013 22:46, Martin Vaeth
wrote:
> Kent Fredric 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
On 28 September 2013 22:31, Martin Vaeth
wrote:
>
> 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 ,
because upstreams versionin
Kent Fredric 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 from the
other posti
Kent Fredric 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 follows what the perl
Matt Turner 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 happens, bec
On 28 September 2013 07:48, Martin Vaeth
wrote:
> Sorry if this is duplicate: I repost since I cannot see it after
> a few hours.
>
> Kent Fredric wrote:
> >
> > On 27 September 2013 08:02, Martin Vaeth
> >wrote:
> >
> >> For those which are provided by perl itself, you could have
> >> a correspo
On Fri, Sep 27, 2013 at 12:48 PM, Martin Vaeth
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 particular version, if I do not want t
Sorry if this is duplicate: I repost since I cannot see it after
a few hours.
Kent Fredric wrote:
>
> On 27 September 2013 08:02, Martin Vaeth
>wrote:
>
>> 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
On 27 September 2013 08:02, Martin Vaeth
wrote:
> 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 the corresponding package as a
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 de
Kent Fredric wrote:
>
> On 27 September 2013 05:57, Ciaran McCreesh
>wrote:
>
>> 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 make a use dependency:
If the main perl tarba
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 devel
-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 Thu, 26 Sep 2013 21:14:11 +1000
Michael Palimaka wrote:
> On 26/09/2013 20:55, Ciaran McCreesh wrote:
> > On Thu, 26 Sep 2013 20:51:26 +1000
> > Michael Palimaka wrote:
> >> There isn't a 100% perfect solution currently, and I agree that
> >> hurrying people will simply move us from "not enoug
On 26/09/2013 20:55, Ciaran McCreesh wrote:
On Thu, 26 Sep 2013 20:51:26 +1000
Michael Palimaka 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.
At
On Thu, 26 Sep 2013 20:51:26 +1000
Michael Palimaka 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
signature.asc
Descriptio
On 26/09/2013 17:53, Michał Górny wrote:
Dnia 2013-09-26, o godz. 15:15:38
Patrick Lauer napisał(a):
Thus I suggest declaring a policy:
""
Any library bump that would trigger revdep-rebuild should be done with
the affected library package.mask'ed until all its consumers have been
properly bum
29 matches
Mail list logo
