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
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 info :)
signature.asc
Description: This is a digitally signed me
45 matches
Mail list logo
