Am Donnerstag, den 09.04.2009, 23:36 +0530 schrieb Nirbheek Chauhan:
> On Thu, Apr 9, 2009 at 10:15 PM, Tiziano Müller wrote:
> > roughly 90% packages depending on one of:
> >
> > sys-libs/db
>
> Why the hell does this have so many slots in-tree? I am unaware of the
> reasons for it. Horribly cha
On Thursday 09 April 2009 19:06:16 Nirbheek Chauhan wrote:
> > dev-lang/python
>
> So, wait, you want to depend on specific slots of python and keep them
> around, and manage all their related bugs? Isn't that exactly the
> opposite of what python upstream suggests, and *ALL* distros do?
If you in
On Thu, Apr 9, 2009 at 10:15 PM, Tiziano Müller wrote:
> roughly 90% packages depending on one of:
>
> sys-libs/db
Why the hell does this have so many slots in-tree? I am unaware of the
reasons for it. Horribly changed API every release? How does every
other distro handle sys-libs/db ?
> dev-lib
Am Donnerstag, den 09.04.2009, 12:03 +0200 schrieb Rémi Cardona:
> Mart Raudsepp a écrit :
> > Hello,
> >
> >
> > This thread is for any discussion about the slot operator support item
> > in EAPI-3 draft.
>
> Could anyone actually give a good reason for slot operators? What
> packages would ha
On Thu, 09 Apr 2009 05:25:33 +0300
Mart Raudsepp wrote:
> Are we sure := and :* is the syntax that makes sense once we try to
> cover some of the above with new syntax?
:= and :* covers the cases that can be covered with existing dependency
ranges. If you want to cover things that need horrible |
On Thu, 9 Apr 2009 17:06:47 +0530
Nirbheek Chauhan wrote:
> So you're looking for ABI deps? @preserved-libs is the answer (C-sharp
> support for that?). Suggested rebuilds upon upgrade? Separate issue,
> separate solution (pkg_pretend maybe?)
@preserved-libs is a horrible hack that is used in pl
On Thu, Apr 9, 2009 at 4:56 PM, Peter Alfredsen wrote:
> As I said, I would be using slot-deps as ABI-deps. I would find actual
> ABI deps to be vastly more useful since I wouldn't have to keep track
> of earlier slots to block.
>
> Imagine a world with no revdep-rebuild?
>
So you're looking for
On Thu, 9 Apr 2009 16:29:53 +0530
Nirbheek Chauhan wrote:
> I think the current way is the most easily-supportable way for us.
> Complex interdependencies b/w packages and slots => O(n^k) times bugs,
> where k = no. of slots for a library.
>
> If we don't get all those bugs, it means people are
On N, 2009-04-09 at 11:30 +0200, Tiziano Müller wrote:
> Am Donnerstag, den 09.04.2009, 05:25 +0300 schrieb Mart Raudsepp:
> > Hello,
> >
> >
> > This thread is for any discussion about the slot operator support item
> > in EAPI-3 draft.
> >
> > The premise is good what := and :* allow for, but
On Thu, Apr 9, 2009 at 4:09 PM, Peter Alfredsen wrote:
> All package depending on dev-dotnet/gtk-sharp. Although these won't be
> parallel-installable slots, it will really easy the transition between
> versions and allow us to ease the currently quite strict
> interdependencies between the variou
On Thu, 09 Apr 2009 12:03:03 +0200
Rémi Cardona wrote:
> Could anyone actually give a good reason for slot operators? What
> packages would have a _clear_ benefit from using them? I'm asking for
> an actual list of packages, not just some package that may exist in a
> parallel universe.
All pa
Mart Raudsepp a écrit :
Hello,
This thread is for any discussion about the slot operator support item
in EAPI-3 draft.
Could anyone actually give a good reason for slot operators? What
packages would have a _clear_ benefit from using them? I'm asking for an
actual list of packages, not just
Am Donnerstag, den 09.04.2009, 05:25 +0300 schrieb Mart Raudsepp:
> Hello,
>
>
> This thread is for any discussion about the slot operator support item
> in EAPI-3 draft.
>
> The premise is good what := and :* allow for, but I'm concerned about
> the syntax possibly ending up being suboptimal in
Hello,
This thread is for any discussion about the slot operator support item
in EAPI-3 draft.
The premise is good what := and :* allow for, but I'm concerned about
the syntax possibly ending up being suboptimal in relation to the syntax
we come up in the future for covering the cases not covere
14 matches
Mail list logo