On Sat, 28 Apr 2012 10:09:01 +
Francesco Riosa wrote:
> What's changed from 2006 in version handling?
The ordering rules, the handling of zeroes and the behaviour of
suffixes.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
What's changed from 2006 in version handling?
Il giorno 28/apr/2012 11:39, "Ciaran McCreesh" <
ciaran.mccre...@googlemail.com> ha scritto:
>
> On Sat, 28 Apr 2012 10:52:07 +0200
> Michał Górny wrote:
> > On Fri, 27 Apr 2012 21:12:27 +0100
> > Ciaran McCreesh wrote:
> > > * Get a versionator repla
On Sat, 28 Apr 2012 10:52:07 +0200
Michał Górny wrote:
> On Fri, 27 Apr 2012 21:12:27 +0100
> Ciaran McCreesh wrote:
> > * Get a versionator replacement into the PM
>
> Why are we trying to make PM a brick instead of keeping stuff modular?
> What does the eclass lack which could be provided by P
On Fri, 27 Apr 2012 21:12:27 +0100
Ciaran McCreesh wrote:
> * Get a versionator replacement into the PM
Why are we trying to make PM a brick instead of keeping stuff modular?
What does the eclass lack which could be provided by PM?
--
Best regards,
Michał Górny
signature.asc
Description: PGP
El vie, 27-04-2012 a las 21:12 +0100, Ciaran McCreesh escribió:
> On Fri, 27 Apr 2012 21:58:24 +0200
> Michał Górny wrote:
> > Of course, if we take the 'quick EAPI 5 route', it won't include
> > anything useful. In the meantime, do we have a complete list of
> > candidates for EAPI 5?
>
> Let's
Nikos Chantziaras posted on Fri, 27 Apr 2012 18:55:12 +0300 as excerpted:
> On 27/04/12 17:15, Duncan wrote:
>> Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted:
>>> Having the package manager interact with an eclass function like
>>> epatch_user is ugly, and it's unnecessary sinc
On Fri, 27 Apr 2012 21:58:24 +0200
Michał Górny wrote:
> Of course, if we take the 'quick EAPI 5 route', it won't include
> anything useful. In the meantime, do we have a complete list of
> candidates for EAPI 5?
Let's continue this on the PMS list.
* user patches
* EAPI parsing
* the things t
On Fri, 27 Apr 2012 21:43:06 +0200
Ulrich Mueller wrote:
> > On Fri, 27 Apr 2012, Ciaran McCreesh wrote:
>
> >> Did I get it right, you are thinking about a special EAPI only for
> >> user patches? I'd say that the feature is not important enough to
> >> justify that.
>
> > Didn't we have a
> On Fri, 27 Apr 2012, Ciaran McCreesh wrote:
>> Did I get it right, you are thinking about a special EAPI only for
>> user patches? I'd say that the feature is not important enough to
>> justify that.
> Didn't we have a few other cheap things lined up?
Yes we do, and IMHO it would make much
On Fri, 27 Apr 2012 20:01:15 +0200
Ulrich Mueller wrote:
> > Since we've managed to survive up to this point without such a
> > feature, I think it's worth the wait roll it into EAPI 5 and have a
> > clean solution that doesn't rely on package manager interaction with
> > eclasses. If we quickly d
On 04/27/2012 11:57 AM, Michał Górny wrote:
> On Fri, 27 Apr 2012 20:01:15 +0200
> Ulrich Mueller wrote:
>
>>> On Fri, 27 Apr 2012, Zac Medico wrote:
>>
>>> Since we've managed to survive up to this point without such a
>>> feature, I think it's worth the wait roll it into EAPI 5 and have a
>
On Fri, 27 Apr 2012 20:01:15 +0200
Ulrich Mueller wrote:
> > On Fri, 27 Apr 2012, Zac Medico wrote:
>
> > Since we've managed to survive up to this point without such a
> > feature, I think it's worth the wait roll it into EAPI 5 and have a
> > clean solution that doesn't rely on package man
On Fri, Apr 27, 2012 at 11:01 AM, Ulrich Mueller wrote:
>> On Fri, 27 Apr 2012, Zac Medico wrote:
>
>> Since we've managed to survive up to this point without such a
>> feature, I think it's worth the wait roll it into EAPI 5 and have a
>> clean solution that doesn't rely on package manager in
On 04/27/2012 11:01 AM, Ulrich Mueller wrote:
>> On Fri, 27 Apr 2012, Zac Medico wrote:
>
>> Since we've managed to survive up to this point without such a
>> feature, I think it's worth the wait roll it into EAPI 5 and have a
>> clean solution that doesn't rely on package manager interaction
> On Fri, 27 Apr 2012, Zac Medico wrote:
> Since we've managed to survive up to this point without such a
> feature, I think it's worth the wait roll it into EAPI 5 and have a
> clean solution that doesn't rely on package manager interaction with
> eclasses. If we quickly draft an EAPI 5 spec,
On 04/27/2012 07:20 AM, Michał Górny wrote:
> We could finally decide it'll be a Portage internal feature, and modify
> epatch_user() to export some Portage-specific indication that user
> patches were applied.
Since we've managed to survive up to this point without such a feature,
I think it's wo
On 27/04/12 17:15, Duncan wrote:
Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted:
Having the package manager interact with an eclass function like
epatch_user is ugly, and it's unnecessary since we can pull all of the
pieces into the package manager in EAPI 5. Any eclasses that
On 04/27/2012 09:11 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 09:08:06 -0700
> Zac Medico wrote:
>>> But there's no way the repoman check is going to give anything like
>>> reliable answers if you're involving eclasses...
>>
>> Okay, so people who need "reliable answers" can go with your st
On Fri, 27 Apr 2012 09:08:06 -0700
Zac Medico wrote:
> > But there's no way the repoman check is going to give anything like
> > reliable answers if you're involving eclasses...
>
> Okay, so people who need "reliable answers" can go with your strict
> approach. Meanwhile, it's relatively easy to
On 04/27/2012 09:00 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 08:55:49 -0700
> Zac Medico wrote:
>> I suppose that we could do it both ways. The repoman check would be
>> for people who want a practical approach that doesn't require all
>> ebuilds to be converted to EAPI 5, and your strict
On Fri, 27 Apr 2012 08:55:49 -0700
Zac Medico wrote:
> I suppose that we could do it both ways. The repoman check would be
> for people who want a practical approach that doesn't require all
> ebuilds to be converted to EAPI 5, and your strict die approach would
> be for people who want strictness
On 04/27/2012 08:45 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 08:41:35 -0700
> Zac Medico wrote:
>>> In order to make it globally available, you put it in EAPI 5, and
>>> make the package mangler die at pretend time if the user has patches
>>> specified for a package that isn't EAPI 5.
>>
>
On Fri, 27 Apr 2012 08:41:35 -0700
Zac Medico wrote:
> > In order to make it globally available, you put it in EAPI 5, and
> > make the package mangler die at pretend time if the user has patches
> > specified for a package that isn't EAPI 5.
>
> Or, have repoman assert that src_prepare contains
On 04/27/2012 07:27 AM, Ciaran McCreesh wrote:
> On Fri, 27 Apr 2012 14:15:35 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
>> In ordered to make it globally available, it cannot simply be an
>> EAPI-5 thing, it must apply to all current ebuilds whether they (or
>> an inherited eclass) call ep
On Fri, 27 Apr 2012 14:15:35 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> In ordered to make it globally available, it cannot simply be an
> EAPI-5 thing, it must apply to all current ebuilds whether they (or
> an inherited eclass) call epatch_user or not. Which means that
> conflict with th
On Fri, 27 Apr 2012 14:15:35 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted:
>
> > On 04/26/2012 03:08 PM, Duncan wrote:
> >> Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted:
> >>> Also, don't forget to consid
Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted:
> On 04/26/2012 03:08 PM, Duncan wrote:
>> Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted:
>>> Also, don't forget to consider the possibility of interference between
>>> FEATURES=userpatch and epatch_user (applyi
On 04/26/2012 03:08 PM, Duncan wrote:
Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted:
Also, don't forget to consider the possibility of interference between
FEATURES=userpatch and epatch_user (applying same patches twice).
The existing phaselock-file solution should continue
Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted:
> On 04/26/2012 02:55 AM, Duncan wrote:
>> Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted:
>>
>>> On 04/25/2012 11:18 PM, Duncan wrote:
IOW, let's quit letting the perfect be the enemy of the good
>>> If th
On Thu, 26 Apr 2012 20:50:02 +0200
Michał Górny wrote:
> > So the package manager is supposed to interact with an eclass
> > function? That's pretty ugly. Why not just roll out a quick EAPI 5
> > that adds support for the "apply_user_patches_here" approach [1]?
> >
> > http://archives.gentoo.org/
On Thu, 26 Apr 2012 11:43:37 -0700
Zac Medico wrote:
> On 04/26/2012 11:27 AM, Michał Górny wrote:
> > On Thu, 26 Apr 2012 06:18:32 + (UTC)
> > Duncan <1i5t5.dun...@cox.net> wrote:
> >
> >> My suggestion is therefore to do the simple thing, just apply any
> >> patches found in the patches di
On 04/26/2012 11:27 AM, Michał Górny wrote:
> On Thu, 26 Apr 2012 06:18:32 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
>
>> My suggestion is therefore to do the simple thing, just apply any
>> patches found in the patches dir, and punt on the complicated
>> do-we-eautoreconf- or-not thing.
On Thu, 26 Apr 2012 06:18:32 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> My suggestion is therefore to do the simple thing, just apply any
> patches found in the patches dir, and punt on the complicated
> do-we-eautoreconf- or-not thing.
Agreed. Just make sure the feature will be only used
On 04/26/2012 02:55 AM, Duncan wrote:
Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted:
On 04/25/2012 11:18 PM, Duncan wrote:
IOW, let's quit letting the perfect be the enemy of the good, and just
get on with it, already.
If that means settling on something that's fragile an
Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted:
> On 04/25/2012 11:18 PM, Duncan wrote:
>> IOW, let's quit letting the perfect be the enemy of the good, and just
>> get on with it, already.
>
> If that means settling on something that's fragile and prone to lots of
> bug report
On 04/25/2012 11:18 PM, Duncan wrote:
> IOW, let's quit letting the perfect be the enemy of the good, and just
> get on with it, already.
If that means settling on something that's fragile and prone to lots of
bug reports, then it's not really practical, because it wastes peoples
time (and time i
Ryan Hill posted on Wed, 25 Apr 2012 22:44:33 -0600 as excerpted:
> On Wed, 18 Apr 2012 22:41:39 +0100 David Leverton
> wrote:
>
>> The point I was trying to get at was that it seems a bit heavyweight to
>> rely on a whole eclass for a minor use-case, as well as a bit
>> error-prone to expect pe
On Wed, 25 Apr 2012 22:03:18 -0700
Zac Medico wrote:
> On 04/25/2012 09:44 PM, Ryan Hill wrote:
> > Yeah the whole idea here was to make user patches available without ebuild
> > modifications or eclass dependence.
> Using the "apply_user_patches_here" approach [1] that Ciaran suggested,
> the
On 04/25/2012 09:44 PM, Ryan Hill wrote:
> On Wed, 18 Apr 2012 22:41:39 +0100
> David Leverton wrote:
>
>> The point I was trying to get at was that it seems a bit heavyweight to
>> rely on a whole eclass for a minor use-case, as well as a bit
>> error-prone to expect people to remember it ever
On Wed, 18 Apr 2012 22:41:39 +0100
David Leverton wrote:
> The point I was trying to get at was that it seems a bit heavyweight to
> rely on a whole eclass for a minor use-case, as well as a bit
> error-prone to expect people to remember it every time, but maybe that's
> the least bad option a
On 04/22/2012 10:04 PM, Steven J Long wrote:
> It seems there's two major cases, with autotools or without. In either case,
> epatch_user should be called after Gentoo patches have been applied.
>
> Why not make epatch_user set a variable to indicate that patches have been
> applied, and only ap
Ryan Hill wrote:
> Zac Medico wrote:
>> Funtoo has support for FEATURES=localpatch, which does the epatch_user
>> thing before src_prepare. I think it should really go after src_prepare,
>> in order to apply patches after those that src_prepare may apply
>> (avoiding possible conflicts).
>
> I agr
Sergei Trofimovich posted on Sun, 15 Apr 2012 12:25:12 +0300 as excerpted:
> On Sun, 15 Apr 2012 16:53:04 +0800 Patrick Lauer
> wrote:
>
>> On 04/15/12 16:16, Ryan Hill wrote:
>> > Right now we have support in some packages for user patches - those
>> > being patches dropped into /etc/portage/pa
On 2012-04-15, at 5:03 AM, Ryan Hill wrote:
> On Sun, 15 Apr 2012 01:35:40 -0700
> Zac Medico wrote:
>
>> On 04/15/2012 01:16 AM, Ryan Hill wrote:
>>> Right now we have support in some packages for user patches - those being
>>> patches dropped into /etc/portage/patches/pkgname/ - which are a
On 04/15/2012 02:03 AM, Ryan Hill wrote:
>> The reason that Funtoo's FEATURES=localpatch applies patches before
>> src_prepare is that it's common for eautoreconf to be called inside
>> src_prepare, and applying patches after src_prepare can create a need to
>> call eautoreconf a second time.
>
>
On Sun, 15 Apr 2012 16:53:04 +0800
Patrick Lauer wrote:
> On 04/15/12 16:16, Ryan Hill wrote:
> > Right now we have support in some packages for user patches - those being
> > patches dropped into /etc/portage/patches/pkgname/ - which are automatically
> > applied. Because this feature is implem
On Sun, 15 Apr 2012 01:35:40 -0700
Zac Medico wrote:
> On 04/15/2012 01:16 AM, Ryan Hill wrote:
> > Right now we have support in some packages for user patches - those being
> > patches dropped into /etc/portage/patches/pkgname/ - which are automatically
> > applied. Because this feature is impl
47 matches
Mail list logo
