On Thu, 2012-06-21 at 13:25 +0100, Ciaran McCreesh wrote:
> On Thu, 21 Jun 2012 07:04:41 -0500
> Homer Parker wrote:
> > Damnit, let the user shoot themself in the foot but let them
> > learn from it. Remember back in the day when you had no clue? You
> > learned from it. You can only protect
On Thu, 21 Jun 2012 07:04:41 -0500
Homer Parker wrote:
> Damnit, let the user shoot themself in the foot but let them
> learn from it. Remember back in the day when you had no clue? You
> learned from it. You can only protect them so much. If they want to
> use custom patches then they need
On Wed, 2012-06-20 at 17:50 +0100, Ciaran McCreesh wrote:
>
> > Then there are ebuilds that don't call eautoreconf, in the first
> > place. Should we require that all of them inherit autotools now,
> just
> > for the unlikely case that user patches could be applied?
>
> If the aim is to provide a
On Wed, 20 Jun 2012 18:45:31 +0200
Ulrich Mueller wrote:
> I'd say that EAPI 5 should provide an "apply_patches_here" function
> that can be called by ebuilds, but if the ebuild hasn't called the
> function, then it should fall back to applying user patches just after
> src_prepare.
But applying
> On Wed, 20 Jun 2012, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 17:44:36 +0200
> Ulrich Mueller wrote:
>> I disagree with this. As it is currently worded, every ebuild would
>> be required to call a special function in src_prepare. This is the
>> worst possible solution, IMHO.
> Every eb
On Wed, 20 Jun 2012 17:44:36 +0200
Ulrich Mueller wrote:
> > On Wed, 20 Jun 2012, Ciaran McCreesh wrote:
> > I believe we consider the user patches feature to be finalised,
> > [...]
>
> I disagree with this. As it is currently worded, every ebuild would be
> required would be required to cal
> On Wed, 20 Jun 2012, Ciaran McCreesh wrote:
> I believe we consider the user patches feature to be finalised, [...]
I disagree with this. As it is currently worded, every ebuild would be
required would be required to call a special function in src_prepare.
This is the worst possible solutio
On Wed, 20 Jun 2012 13:22:22 +0200
Michał Górny wrote:
> > I believe we consider the user patches feature to be finalised, so
> > if you want something else, it should be treated as a new feature
> > rather than a change. But please don't rehash anything that's
> > already been covered.
>
> I sim
On Wed, 20 Jun 2012 12:14:38 +0100
Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 13:12:25 +0200
> Michał Górny wrote:
> > On Wed, 20 Jun 2012 12:02:42 +0100
> > Ciaran McCreesh wrote:
> > > Please don't. User patches were discussed on this list, and
> > > there's already wording written. We don'
On Wed, 20 Jun 2012 13:12:25 +0200
Michał Górny wrote:
> On Wed, 20 Jun 2012 12:02:42 +0100
> Ciaran McCreesh wrote:
> > Please don't. User patches were discussed on this list, and there's
> > already wording written. We don't need a bug to track it.
>
> So you want requests here or do I have do
On Wed, 20 Jun 2012 12:02:42 +0100
Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 11:07:55 +0200
> Michał Górny wrote:
> > Could someone open bugs for all of that? I was looking for user
> > patches on the future EAPI tracker, and I don't see it there.
>
> Please don't. User patches were discusse
On Wed, 20 Jun 2012 11:07:55 +0200
Michał Górny wrote:
> Could someone open bugs for all of that? I was looking for user
> patches on the future EAPI tracker, and I don't see it there.
Please don't. User patches were discussed on this list, and there's
already wording written. We don't need a bug
On Sat, 16 Jun 2012 14:12:13 +0200
Ulrich Mueller wrote:
> > On Sat, 16 Jun 2012, Pacho Ramos wrote:
>
> > I would like to know if there is some place where things going to be
> > included (or proposed to be included) for eapi5 are listed (if such
> > place exists). Currently, looks like the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/06/12 12:24 PM, Ciaran McCreesh wrote:
> On Sat, 16 Jun 2012 17:16:34 +0200 Pacho Ramos
> wrote:
>> I can try to check it if no maintainer shows more packages
>> showing this stable API unstable ABIs issues
>
> Please do. This is a fairly im
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/06/12 12:18 PM, Ciaran McCreesh wrote:
> On Sat, 16 Jun 2012 17:24:22 +0200 Peter Stuge
> wrote:
>> Ciaran McCreesh wrote:
Could it work to make automatic signatures of imported ABI,
and simply compare signatures when a provider pack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/06/12 09:37 AM, Pacho Ramos wrote:
> El sáb, 16-06-2012 a las 13:43 +0100, Ciaran McCreesh escribió:
>> On Sat, 16 Jun 2012 14:26:16 +0200 Pacho Ramos
>> wrote:
>>> About suggesting new item (like forcing rebuilding of other
>>> packages as di
On Sun, 2012-06-17 at 13:35 +0200, Peter Stuge wrote:
> Hans de Graaff wrote:
> > > I think ABI fits well though? The situation is that A DEPENDs on B,
> > > and at some point B changes in a way that A must be rebuilt in order
> > > to run - right?
> >
> > At least for dev-ruby/nokogiri this is no
On Saturday 16 June 2012 08:12:13 Ulrich Mueller wrote:
> > On Sat, 16 Jun 2012, Pacho Ramos wrote:
> > I would like to know if there is some place where things going to be
> > included (or proposed to be included) for eapi5 are listed (if such
> > place exists). Currently, looks like there is
Hans de Graaff wrote:
> > I think ABI fits well though? The situation is that A DEPENDs on B,
> > and at some point B changes in a way that A must be rebuilt in order
> > to run - right?
>
> At least for dev-ruby/nokogiri this is not the case. It checks the
> version of libxml2 it was built agains
On Sat, 2012-06-16 at 17:24 +0200, Peter Stuge wrote:
> Ciaran McCreesh wrote:
> > Also, can we stop using the term "ABI" in reference to this please?
> > It's misleading. Let's call them sub-slots instead.
>
> I think ABI fits well though? The situation is that A DEPENDs on B,
> and at some poin
On Sat, 16 Jun 2012 20:59:18 +0200
Pacho Ramos wrote:
> > Naah. This is one of those things that requires developers to put
> > quite a lot of exta effort in to their packages in order to improve
> > the quality of experience for users, which means it's not going to
> > be suitable for Gentoo's de
El sáb, 16-06-2012 a las 17:46 +0100, Ciaran McCreesh escribió:
> On Sat, 16 Jun 2012 18:41:51 +0200
> Pacho Ramos wrote:
> > > The :*/:= feature was designed to solve one specific problem: if a
> > > user has foo installed, and foo deps upon bar, and bar:1 is
> > > installed, and the user wants t
On Sat, 16 Jun 2012 18:41:51 +0200
Pacho Ramos wrote:
> > The :*/:= feature was designed to solve one specific problem: if a
> > user has foo installed, and foo deps upon bar, and bar:1 is
> > installed, and the user wants to install bar:2 and then uninstall
> > bar:1, will foo break? :* means no,
El sáb, 16-06-2012 a las 17:24 +0100, Ciaran McCreesh escribió:
> On Sat, 16 Jun 2012 17:16:34 +0200
> Pacho Ramos wrote:
> > El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió:
> > > On Sat, 16 Jun 2012 16:48:20 +0200
> > > Pacho Ramos wrote:
> > > > Regarding the comparison with usi
On Sat, 16 Jun 2012 17:16:34 +0200
Pacho Ramos wrote:
> El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió:
> > On Sat, 16 Jun 2012 16:48:20 +0200
> > Pacho Ramos wrote:
> > > Regarding the comparison with using only SLOT, the most clear
> > > example of how that solution was a bit wo
On Sat, 16 Jun 2012 17:24:22 +0200
Peter Stuge wrote:
> Ciaran McCreesh wrote:
> > > Could it work to make automatic signatures of imported ABI, and
> > > simply compare signatures when a provider package is updated?
> >
> > No.
>
> Can you say why?
There's no way for a program to work out what
Ciaran McCreesh wrote:
> > Could it work to make automatic signatures of imported ABI, and
> > simply compare signatures when a provider package is updated?
>
> No.
Can you say why?
> Also, can we stop using the term "ABI" in reference to this please?
> It's misleading. Let's call them sub-slot
El sáb, 16-06-2012 a las 17:16 +0200, Pacho Ramos escribió:
> El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió:
> > On Sat, 16 Jun 2012 16:48:20 +0200
> > Pacho Ramos wrote:
> > > Regarding the comparison with using only SLOT, the most clear example
> > > of how that solution was a b
El sáb, 16-06-2012 a las 15:52 +0100, Ciaran McCreesh escribió:
> On Sat, 16 Jun 2012 16:48:20 +0200
> Pacho Ramos wrote:
> > Regarding the comparison with using only SLOT, the most clear example
> > of how that solution was a bit worse was that glib vs
> > dbus-glib/gobject-introspection handling
On Sat, 16 Jun 2012 17:06:07 +0200
Peter Stuge wrote:
> Could it work to make automatic signatures of imported ABI, and
> simply compare signatures when a provider package is updated?
No.
Also, can we stop using the term "ABI" in reference to this please?
It's misleading. Let's call them sub-slo
Pacho Ramos wrote:
> What I try to do is to replace the needing of manually rebuilding
> packages after updates due ABI changes
Does this really require explicit ABI information in ebuilds?
Could it work to make automatic signatures of imported ABI, and
simply compare signatures when a provider p
On Sat, 16 Jun 2012 16:48:20 +0200
Pacho Ramos wrote:
> El sáb, 16-06-2012 a las 15:31 +0100, Ciaran McCreesh escribió:
> > On Sat, 16 Jun 2012 16:29:09 +0200
> > Pacho Ramos wrote:
> > > I thought last Zac suggestion of ABI_SLOT modified to use
> > > "SLOT=ble/bla" was clear enough and we reach
On Sat, 16 Jun 2012 16:48:20 +0200
Pacho Ramos wrote:
> Regarding the comparison with using only SLOT, the most clear example
> of how that solution was a bit worse was that glib vs
> dbus-glib/gobject-introspection handling:
> - Using only SLOT with := would end up with we needing to update
> ebu
El sáb, 16-06-2012 a las 15:31 +0100, Ciaran McCreesh escribió:
> On Sat, 16 Jun 2012 16:29:09 +0200
> Pacho Ramos wrote:
> > I thought last Zac suggestion of ABI_SLOT modified to use
> > "SLOT=ble/bla" was clear enough and we reached a consensus.
>
> Possibly. I'm waiting to see an implementatio
On Sat, 16 Jun 2012 16:29:09 +0200
Pacho Ramos wrote:
> I thought last Zac suggestion of ABI_SLOT modified to use
> "SLOT=ble/bla" was clear enough and we reached a consensus.
Possibly. I'm waiting to see an implementation, a bunch of examples and
a comparison with just using SLOT and := or :*.
El sáb, 16-06-2012 a las 14:48 +0100, Ciaran McCreesh escribió:
> On Sat, 16 Jun 2012 15:37:44 +0200
> Pacho Ramos wrote:
> > > > About suggesting new item (like forcing rebuilding of other
> > > > packages as discussed some days ago and crosscompile support
> > > > suggested by Tommy today), I gu
On Sat, 16 Jun 2012 15:37:44 +0200
Pacho Ramos wrote:
> > > About suggesting new item (like forcing rebuilding of other
> > > packages as discussed some days ago and crosscompile support
> > > suggested by Tommy today), I guess we need to get them voted by
> > > the council?
> >
> > No. You need
El sáb, 16-06-2012 a las 13:43 +0100, Ciaran McCreesh escribió:
> On Sat, 16 Jun 2012 14:26:16 +0200
> Pacho Ramos wrote:
> > OK, would you let me to create a tracker bug for eapi5 accepted item?
>
> No. We're working on the PMS list. We don't need yet another place to
> look.
>
> > About sugges
On 16.06.2012 14:26, Pacho Ramos wrote:
> El sáb, 16-06-2012 a las 14:12 +0200, Ulrich Mueller escribió:
>>> On Sat, 16 Jun 2012, Pacho Ramos wrote:
>>
>>> I would like to know if there is some place where things going to be
>>> included (or proposed to be included) for eapi5 are listed (if suc
On Sat, 16 Jun 2012 14:26:16 +0200
Pacho Ramos wrote:
> OK, would you let me to create a tracker bug for eapi5 accepted item?
No. We're working on the PMS list. We don't need yet another place to
look.
> About suggesting new item (like forcing rebuilding of other packages
> as discussed some day
El sáb, 16-06-2012 a las 14:12 +0200, Ulrich Mueller escribió:
> > On Sat, 16 Jun 2012, Pacho Ramos wrote:
>
> > I would like to know if there is some place where things going to be
> > included (or proposed to be included) for eapi5 are listed (if such
> > place exists). Currently, looks like
> On Sat, 16 Jun 2012, Pacho Ramos wrote:
> I would like to know if there is some place where things going to be
> included (or proposed to be included) for eapi5 are listed (if such
> place exists). Currently, looks like there is no eapi5 tracker :-/
The PMS git repository has an eapi-5 deve
El sáb, 16-06-2012 a las 13:13 +0200, Agostino Sarubbo escribió:
> On Saturday 16 June 2012 12:55:22 Pacho Ramos wrote:
> > Hello
> >
> > I would like to know if there is some place where things going to be
> > included (or proposed to be included) for eapi5 are listed (if such
> > place exists).
On Saturday 16 June 2012 12:55:22 Pacho Ramos wrote:
> Hello
>
> I would like to know if there is some place where things going to be
> included (or proposed to be included) for eapi5 are listed (if such
> place exists). Currently, looks like there is no eapi5 tracker :-/
>
> Thanks a lot for the
44 matches
Mail list logo
