Hi,
Andrew D Kirch :
> Ryan Hill wrote:
> > On Fri, 21 Aug 2009 17:29:12 -0700
> > Chip Parker wrote:
> >
> >
> >> If you were building a house, and the blueprints had been signed
> >> off on calling for 1 meter high doors, but the builder had built
> >> in 2 meter high doors, would you then
On Saturday 22 August 2009, Chip Parker wrote:
> 2009/8/21 Robert Buchholz :
> > On Saturday 22 August 2009, Maciej Mrozowski wrote:
> >> It's true, but being able to modularize profile may outweights the
> >> need to be strict-with-the-book here - it's a matter of usefulness. I
> >> think it shoul
On Sunday 23 August 2009 03:39:52 Arfrever Frehtes Taifersar Arahesis wrote:
> /etc/make.profile is by default a symlink to appropriate profile directory
> in ${PORTDIR}/profiles.
Again, a detail of how Portage is configured. PMS only covers profiles that
are in repositories - it's up to the pac
2009-08-23 02:34:08 Ciaran McCreesh napisał(a):
> On Sat, 22 Aug 2009 17:26:24 -0700
> Chip Parker wrote:
> > Since you have a habit of ignoring relevant bits of technical
> > opposition to some of your more insane schemes, I'll cite *again* the
> > relevant portion.
>
> I showed you the relevant
On Sunday 23 August 2009 02:10:36 Chip Parker wrote:
> They're the same thing. It doesn't matter if the profiles directory is
> in located in /tmp or in /usr/local/portage, the behavior of paludis
> *still* doesn't support the feature that these profiles depend on and
> portage still *HAS* since be
On Sat, 22 Aug 2009 18:10:36 -0700
Chip Parker wrote:
> What you proposed in the bug you filed would specifically break how I
> do things, without replacing it with an equal or better solution.
No it wouldn't. It would have no effect whatsoever on how you do things.
--
Ciaran McCreesh
signatu
On Sat, Aug 22, 2009 at 5:32 PM, David Leverton wrote:
> On Sunday 23 August 2009 01:26:24 Chip Parker wrote:
>> So, Ciaran, if your personal reference implementation of PMS fails
>> miserably when using this methodology, your argument that I won't be
>> or "am not" affected by your attempt at chan
On Sat, 22 Aug 2009 17:26:24 -0700
Chip Parker wrote:
> Since you have a habit of ignoring relevant bits of technical
> opposition to some of your more insane schemes, I'll cite *again* the
> relevant portion.
I showed you the relevant portion. /etc/make.profile means it is user
configuration, wh
On Sunday 23 August 2009 01:26:24 Chip Parker wrote:
> So, Ciaran, if your personal reference implementation of PMS fails
> miserably when using this methodology, your argument that I won't be
> or "am not" affected by your attempt at changing portage is invalid.
> If you'd like to test for yoursel
On Sat, Aug 22, 2009 at 2:52 PM, Ciaran
McCreesh wrote:
> On Sat, 22 Aug 2009 14:47:44 -0700
> Chip Parker wrote:
>> * When loading profiles '/etc/make.profile' for repository 'gentoo':
>
> /etc/make.profile is user configuration, and beyond the scope of PMS.
>
>> Additionally, I plan to show ve
On Sat, 22 Aug 2009 14:47:44 -0700
Chip Parker wrote:
> * When loading profiles '/etc/make.profile' for repository 'gentoo':
/etc/make.profile is user configuration, and beyond the scope of PMS.
> Additionally, I plan to show very soon that PMS is incorrect in its
> requirement that profiles/p
On Fri, Aug 21, 2009 at 5:34 PM, Ciaran
McCreesh wrote:
> On Fri, 21 Aug 2009 17:29:12 -0700
> Chip Parker wrote:
>> If this feature, which HAD been documented (in bugzilla and
>> commitlogs) prior to the first RFC for PMS
>
> As I've already explained to you on bugzilla, this is untrue. You're
>
On Sat, 22 Aug 2009 22:22:54 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-08-22 21:39:47 Ciaran McCreesh napisał(a):
> > On Sat, 22 Aug 2009 01:54:22 +0100
> > AllenJB wrote:
> > > Could there be room for "fast track" EAPI's to be considered on some
> > > occasions - eg. in this case
On Sat, 22 Aug 2009 01:32:33 -0400
Andrew D Kirch wrote:
> Ryan Hill wrote:
> > On Fri, 21 Aug 2009 17:29:12 -0700
> > Chip Parker wrote:
> >
> >
> >> If you were building a house, and the blueprints had been signed off
> >> on calling for 1 meter high doors, but the builder had built in 2
>
On Sat, 22 Aug 2009 22:22:54 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> > Another possibly nicer option would be to add the feature into EAPI
> > 3. However, if we're considering this, we'd have to be absolutely
> > totally clear that this isn't a call to open up EAPI 3 for yet more
> > ch
2009-08-22 21:39:47 Ciaran McCreesh napisał(a):
> On Sat, 22 Aug 2009 01:54:22 +0100
> AllenJB wrote:
> > Could there be room for "fast track" EAPI's to be considered on some
> > occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with
> > the "package.* as directory in profiles" featu
On Sat, 22 Aug 2009 01:54:22 +0100
AllenJB wrote:
> Could there be room for "fast track" EAPI's to be considered on some
> occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with
> the "package.* as directory in profiles" feature included?
It's a possibility, since it's zero cost for
Am Samstag, den 22.08.2009, 02:23 -0400 schrieb Andrew D Kirch:
> Tiziano Müller wrote:
> > As you can see currently, most time is needed to implemente the features
> > in portage. It therefore doesn't make sense to make the EAPI process
> > even faster. On the other hand, I think it would make sen
On 8/22/09, Andrew D Kirch wrote:
> Right, this is called "punishing innovation". It's a hobby of
> bureaucrats everywhere.
> It could also be said to be "punishing excellence".
If it wasn't a sort of a bug (some omission in the original PMS?),
then I suppose this could also be described as The
Tiziano Müller wrote:
> As you can see currently, most time is needed to implemente the features
> in portage. It therefore doesn't make sense to make the EAPI process
> even faster. On the other hand, I think it would make sense to have a
> separate group developing new EAPIs instead of the counci
Am Samstag, den 22.08.2009, 01:54 +0100 schrieb AllenJB:
> From what I've seen here, at least part of the problem here stems from
> the fact that this feature won't be considered until EAPI-4, and that
> means it might be a long way off yet. This, in my mind, raises the
> question of whether the cu
Ryan Hill wrote:
> On Fri, 21 Aug 2009 17:29:12 -0700
> Chip Parker wrote:
>
>
>> If you were building a house, and the blueprints had been signed off
>> on calling for 1 meter high doors, but the builder had built in 2
>> meter high doors, would you then go back to the builder and require
>> h
Robert Buchholz posted on Sat, 22 Aug 2009 01:44:51 +0200 as excerpted:
> I wonder what the value of the PMS specification is if every time an
> inconsistency comes up the argument is raised that it should document
> portage behavior. EAPI 1, 2 and 3 have been agreed by the council and
> PMS is in
On Fri, 21 Aug 2009 17:29:12 -0700
Chip Parker wrote:
> If you were building a house, and the blueprints had been signed off
> on calling for 1 meter high doors, but the builder had built in 2
> meter high doors, would you then go back to the builder and require
> him to do something that makes t
Robert Buchholz wrote:
> On Saturday 22 August 2009, Maciej Mrozowski wrote:
>> It's true, but being able to modularize profile may outweights the
>> need to be strict-with-the-book here - it's a matter of usefulness. I
>> think it should be decided by those who actually do the work in
>> profile,
On Fri, 21 Aug 2009 17:29:12 -0700
Chip Parker wrote:
> If this feature, which HAD been documented (in bugzilla and
> commitlogs) prior to the first RFC for PMS
As I've already explained to you on bugzilla, this is untrue. You're
confusing user configuration with the tree. PMS has nothing to say
2009/8/21 Robert Buchholz :
> On Saturday 22 August 2009, Maciej Mrozowski wrote:
>> It's true, but being able to modularize profile may outweights the
>> need to be strict-with-the-book here - it's a matter of usefulness. I
>> think it should be decided by those who actually do the work in
>> prof
On Saturday 22 August 2009, Maciej Mrozowski wrote:
> It's true, but being able to modularize profile may outweights the
> need to be strict-with-the-book here - it's a matter of usefulness. I
> think it should be decided by those who actually do the work in
> profile, whether it's worthy to push t
On Friday 21 of August 2009 23:46:38 Ciaran McCreesh wrote:
> On Fri, 21 Aug 2009 23:42:11 +0200
> PMS accurately reflected the Portage documentation at the time it was
> written and at the time it was approved.
Agreed, but I think it was supposed to reflect Portage 'behaviour' at the
time. Of co
On Fri, 21 Aug 2009 23:42:11 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> > How does changing the portage documentation magically add this to
> > the PMS?
>
> PMS developers are unwilling to fix many bugs in PMS.
This is not a bug in PMS.
PMS accurately reflected the Portage documentation
2009-08-21 23:17:56 Ryan Hill napisał(a):
> On Fri, 21 Aug 2009 16:25:35 +0200
> Arfrever Frehtes Taifersar Arahesis wrote:
>
> > 2009-08-13 07:55:22 Ryan Hill napisał(a):
> > > On Wed, 12 Aug 2009 19:46:56 +0100
> > > Ciaran McCreesh wrote:
> > >
> > > > On Wed, 12 Aug 2009 20:41:30 +0200
> >
On Fri, 21 Aug 2009 16:25:35 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-08-13 07:55:22 Ryan Hill napisał(a):
> > On Wed, 12 Aug 2009 19:46:56 +0100
> > Ciaran McCreesh wrote:
> >
> > > On Wed, 12 Aug 2009 20:41:30 +0200
> > > Tomáš Chvátal wrote:
> > > > Also we should allow the s
2009/8/21 Arfrever Frehtes Taifersar Arahesis :
> Portage documentation has been properly fixed (and the fix will be released
> in next version) and this feature can now be used in 10.0 profiles.
No. Changing the documentation does not retroactively change existing EAPIs.
2009-08-13 07:55:22 Ryan Hill napisał(a):
> On Wed, 12 Aug 2009 19:46:56 +0100
> Ciaran McCreesh wrote:
>
> > On Wed, 12 Aug 2009 20:41:30 +0200
> > Tomáš Chvátal wrote:
> > > Also we should allow the stuff as directory thingus (portage already
> > > handles it right).
> >
> > That's a seperate
On Thu, 20 Aug 2009 11:02:23 +0100
Steven J Long wrote:
> Rémi Cardona wrote:
>
> > Le 18/08/2009 03:30, Steven J Long a écrit :
> > [snip]
> >
> > Steven,
> >
> > This thread was dead for more than 4 days. Yet you pick it up and you
> > try to pick a fight with Ciaran.
> >
> No I was answerin
On Thu, 13 Aug 2009 13:29:04 +0100
Ciaran McCreesh wrote:
> On Wed, 12 Aug 2009 23:55:22 -0600
> Ryan Hill wrote:
> > > That's a seperate thing that needs EAPI control. You'll need to
> > > propose it for EAPI 4 if you want that.
> >
> > Why is that (seriously curious, not disagreeing)? Portag
On Thu, 13 Aug 2009 18:06:04 + (UTC)
Mark Bateman wrote:
> > And it shouldn't be until it's gone through the proper process to
> > become a documented, controlled feature rather than an accident
> > people are exploiting.
> >
> > Seriously, this isn't difficult to do. I get the impression peo
Ciaran McCreesh googlemail.com> writes:
> PMS documents what ebuilds may or may not rely upon from the package
> manager. PMS, like the Portage document, says that package.mask is a
> file.
And main tree ebuild can rely on that. There are no directory-based
package.mask in the main portage tree
On Thu, 13 Aug 2009 17:32:56 + (UTC)
Mark Bateman wrote:
> > It is not the business of PMS to enforce undocumented features that
> > Portage supports only by accident and that aren't used in the tree.
>
> PMS doesn't depict just what portage should do, just what ebuild's in
> the main tree ar
Ciaran McCreesh googlemail.com> writes:
>
> On Thu, 13 Aug 2009 12:50:26 + (UTC)
> Mark Bateman soon.com> wrote:
> > > On Wed, 12 Aug 2009 20:41:30 +0200
> > > Tomáš Chvátal gentoo.org> wrote:
> > > > Also we should allow the stuff as directory thingus (portage
> > > > already handles it r
On Thursday 13 of August 2009 12:35:43 Tiziano Müller wrote:
> Am Mittwoch, den 12.08.2009, 23:55 -0600 schrieb Ryan Hill:
> > On Wed, 12 Aug 2009 19:46:56 +0100
> >
> > Ciaran McCreesh wrote:
> > > On Wed, 12 Aug 2009 20:41:30 +0200
> > >
> > > Tomáš Chvátal wrote:
> > > > Also we should allow t
On Thu, Aug 13, 2009 at 4:05 PM, Tiziano Müller wrote:
> To avoid collision with the current package.mask I'd prefer
> package.mask.d/ for the directory. Also makes the transition easy since
> we can generate package.mask out of the files in package.mask.d/.
>
I completely agree with this. A scrip
On Thu, 13 Aug 2009 12:50:26 + (UTC)
Mark Bateman wrote:
> > On Wed, 12 Aug 2009 20:41:30 +0200
> > Tomáš Chvátal gentoo.org> wrote:
> > > Also we should allow the stuff as directory thingus (portage
> > > already handles it right).
> >
> > That's a seperate thing that needs EAPI control. Yo
Ciaran McCreesh googlemail.com> writes:
>
> On Wed, 12 Aug 2009 20:41:30 +0200
> Tomáš Chvátal gentoo.org> wrote:
> > Also we should allow the stuff as directory thingus (portage already
> > handles it right).
>
> That's a seperate thing that needs EAPI control. You'll need to propose
> it for
On Wed, 12 Aug 2009 23:55:22 -0600
Ryan Hill wrote:
> > That's a seperate thing that needs EAPI control. You'll need to
> > propose it for EAPI 4 if you want that.
>
> Why is that (seriously curious, not disagreeing)? Portage has
> supported this for quite a while now. Does the current PMS disa
Am Mittwoch, den 12.08.2009, 23:55 -0600 schrieb Ryan Hill:
> On Wed, 12 Aug 2009 19:46:56 +0100
> Ciaran McCreesh wrote:
>
> > On Wed, 12 Aug 2009 20:41:30 +0200
> > Tomáš Chvátal wrote:
> > > Also we should allow the stuff as directory thingus (portage already
> > > handles it right).
> >
> >
On Wed, 12 Aug 2009 19:46:56 +0100
Ciaran McCreesh wrote:
> On Wed, 12 Aug 2009 20:41:30 +0200
> Tomáš Chvátal wrote:
> > Also we should allow the stuff as directory thingus (portage already
> > handles it right).
>
> That's a seperate thing that needs EAPI control. You'll need to propose
> it
47 matches
Mail list logo
