On Wed, Aug 24, 2005 at 01:07:42PM +0100, Ciaran McCreesh wrote:
> On Wed, 24 Aug 2005 02:10:04 +0200 Sven Köhler <[EMAIL PROTECTED]> wrote:
> | After the all, the whole mess can IMHO only be cleared up, if there's
> | something like a universal terminal-type, and the application could
> | ask the
On 08/26/05 Brian Harring wrote:
> On Fri, Aug 26, 2005 at 11:44:44AM -0400, Dan Meltzer wrote:
> > Hows the upgrade path RE: end-user useflag changes? Will everyone
> > that has gtk in their make.conf die a horrible death if they don't
> > see the upgrade notice? when will they see the upgrade n
On Fri, Sep 02, 2005 at 07:58:05AM +0200, Marius Mauch wrote:
> On 08/26/05 Brian Harring wrote:
>
> > On Fri, Aug 26, 2005 at 11:44:44AM -0400, Dan Meltzer wrote:
> > > Hows the upgrade path RE: end-user useflag changes? Will everyone
> > > that has gtk in their make.conf die a horrible death if
On 08/26/05 Kristian Benoit wrote:
> On the EAPI subject Brian just brought back, I had this idea that we
> could use the same approch XML took with HTML.
>
> The ebuild could define which EAPI to use, but instead beiing a
> version, the EAPI would be an ebuild API definition. The equivalent to
On 08/27/05 Brian Harring wrote:
> Hola all.
>
> Straight to the point, I'm proposing that the following files-
> arch.list
> categories
> use.desc
> use.local.desc
> package.mask
> updates
>
> be moved out of the profiles directory in the tree, and into the
> existing metadata directory perso
On Fri, Sep 02, 2005 at 08:17:39AM +0200, Marius Mauch wrote:
> On 08/27/05 Brian Harring wrote:
> > Straight to the point, I'm proposing that the following files-
> > arch.list
> > categories
> > use.desc
> > use.local.desc
> > package.mask
> > updates
> >
> > be moved out of the profiles direct
On 08/29/05 Brian Harring wrote:
> That said, it won't work anyways; the aliasing has to occur within the
> python side else it'll screw up the depgraph (realized that just a few
>
> seconds ago) :)
>
> So... back to making a lot of noise, or some python side support for
> aliasing use flags.
On 08/29/05 Brian Harring wrote:
> On Fri, Sep 02, 2005 at 08:17:39AM +0200, Marius Mauch wrote:
> > Don't mind moving them, BUT
> > - metadata is a stupid location for them for several reasons
> being?
> metadata already holds global repository information, time of
> repositories generation, pr
On Fri, Sep 02, 2005 at 09:57:37AM +0200, Marius Mauch wrote:
> On 08/29/05 Brian Harring wrote:
>
> > On Fri, Sep 02, 2005 at 08:17:39AM +0200, Marius Mauch wrote:
> > > Don't mind moving them, BUT
> > > - metadata is a stupid location for them for several reasons
> > being?
> > metadata already
Ciaran McCreesh wrote:
>On Sun, 21 Aug 2005 18:43:54 -0400 Dan Meltzer
><[EMAIL PROTECTED]> wrote:
>| putty pretends to be an xterm and dies at xtermcontrol --get-bg... I
>| can test other things if you need.. just give me some idea :)
>
>Thanks. The other useful one is to see whether it does 256
On Tue, 23 Aug 2005 02:33:53 -0500, Brian Harring wrote
> As stated in 100872, any solution involving centralizing the use
> flags on gstreamer requires use deps.
>
> Can't centralize the use flags on gstreamer till they're available,
> without doing something QA has every right to wedgie you fo
On Mon, 29 Aug 2005 09:28:28 +0200 "ivan vadovič" <[EMAIL PROTECTED]> wrote:
| I think the key thing here is that the application should be able to
| ask the terminal for its feature set.
Should and can are two entirely different things. We're dealing with
reality here and trying to cope with fift
On Mon, Aug 29, 2005 at 02:53:10AM -0500, Brian Harring wrote:
> >
> > Hell no. Don't need to add more confusion to the use flag confusion.
> Instead, confuse the hell out of users who don't religiously follow
> -dev/-user/-gwn, and suddenly get bit by the gtk flag losing it's
> meaning?
>
i li
On Thu, 2005-08-25 at 00:28 -0400, Mike Frysinger wrote:
> - base doesnt define any USE
> - default-linux defines a few local xorg USE (because no one has given us the
> ability to control default USE via IUSE yet :P)
>
> {x86,amd64}/make.defaults has the 'bloated' USE because every single sub x8
On Wed, 2005-08-24 at 21:30 -0500, Kito wrote:
> > So yeah, subprofiles, reasons why not?
>
> Aside from the work involved, I see no reason to not use the cascades
> for what they seem to be made for.
As I understood it, they were implemented to reduce the amount of work
necessary in maintainin
Chris Gianelloni wrote:
On Thu, 2005-08-25 at 00:28 -0400, Mike Frysinger wrote:
- base doesnt define any USE
- default-linux defines a few local xorg USE (because no one has given us the
ability to control default USE via IUSE yet :P)
{x86,amd64}/make.defaults has the 'bloated' USE becau
Chris Gianelloni wrote:
On Wed, 2005-08-24 at 21:30 -0500, Kito wrote:
So yeah, subprofiles, reasons why not?
Aside from the work involved, I see no reason to not use the cascades
for what they seem to be made for.
As I understood it, they were implemented to reduce the amoun
On Sat, 2005-08-27 at 05:01 -0500, Brian Harring wrote:
> What I'm advocating is that the '05 profile (fex) tag in the defaults
> for that profile release, desktop/server agnostic, *system*
> defaults, eg toolchain, pam, nptl, etc. The subprofile the user
> chooses (the desktop or server target
29.8.2005, 17:59:07, Chris Gianelloni wrote:
> I honestly don't think it would be a good idea to forget the lessons of the
> past and start bloating the profiles with tons of "desktop" and "server"
> profiles, among anything else people would want. After all, as soon as we did
> a "desktop" profi
On Sat, 2005-08-27 at 02:46 +0200, Bjarke Istrup Pedersen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I must say I have been wondering about this for a while too.
> A solution might be add some sort of flag to packages that are binary,
> and then let portage install libstdc++ the
On Sat, 2005-08-27 at 03:42 -0500, Brian Harring wrote:
> Further, while no one has yet proposed anything concrete, people have
> been after revamping the profile implementation. Quite likely if/when
> this occurs, it's going to require a seperate directory to avoid any
> issues with older port
On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote:
> As I understood it, they were implemented to reduce the amount of work
> necessary in maintaining them. As it was back then, it required changes
> to an extremely large number of profiles every time a change was made to
> the default USE
If it was an extra ebuild, the profiles directory would need to exist
outside of /usr/portage, would it not? This to prevent it from being
blown up at next sync.
On 8/29/05, Patrick Lauer <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote:
> > As I understood it
On Mon, 2005-08-29 at 20:10 +0200, Patrick Lauer wrote:
> On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote:
> > As I understood it, they were implemented to reduce the amount of work
> > necessary in maintaining them. As it was back then, it required changes
> > to an extremely large numb
On Mon, Aug 29, 2005 at 12:56:35PM -0400, Chris Gianelloni wrote:
> On Sat, 2005-08-27 at 05:01 -0500, Brian Harring wrote:
> Basically, you've taken then 2005.1 profile and made it useless, since
> the stages weren't built against it anyway.
Via that logic (don't change it lest it negates a releas
On Mon, Aug 29, 2005 at 01:27:34PM -0400, Chris Gianelloni wrote:
> This could still be done under profiles. Personally, I like the idea of
> something more like this:
>
> project/os/arch/version for profiles
>
> This would give us something like this:
>
> default/linux/x86/2006.0
> default/fre
> On Mon, 2005-08-29 at 20:10 +0200, Patrick Lauer wrote:
>> On Mon, 2005-08-29 at 11:59 -0400, Chris Gianelloni wrote:
>> > As I understood it, they were implemented to reduce the amount of work
>> > necessary in maintaining them. As it was back then, it required
>> changes
>> > to an extremely l
On Mon, 2005-08-29 at 15:32 -0500, Brian Harring wrote:
> On Mon, Aug 29, 2005 at 12:56:35PM -0400, Chris Gianelloni wrote:
> > On Sat, 2005-08-27 at 05:01 -0500, Brian Harring wrote:
> > Basically, you've taken then 2005.1 profile and made it useless, since
> > the stages weren't built against it
On Mon, 2005-08-29 at 15:36 -0500, Brian Harring wrote:
> On Mon, Aug 29, 2005 at 01:27:34PM -0400, Chris Gianelloni wrote:
> > This could still be done under profiles. Personally, I like the idea of
> > something more like this:
> >
> > project/os/arch/version for profiles
> >
> > This would gi
On Mon, 2005-08-29 at 17:34 -0400, [EMAIL PROTECTED] wrote:
> I think Brian mentioned /etc/portage/profile and other fun portage tricks
> to mess with the default profile. If you think the profile shouldn't be
> changed then don't make it a mutable option. If you think that bugs
> where people f
On Mon, 29 Aug 2005 17:43:35 -0400 Chris Gianelloni
<[EMAIL PROTECTED]> wrote:
| There's nothing stopping you from creating a
| default-linux/x86/ferringb profile and doing whatever you wish in it,
| but editing default-linux/x86/2005.1 without speaking with releng
| would be considered taboo.
Sho
On Mon, Aug 29, 2005 at 05:48:20PM -0400, Chris Gianelloni wrote:
> What other changes are you guys thinking of regarding profiles?
That would be Marius's department. I'm not willing (personally) to
look at revamping profiles till rewrite is finished.
At that point, new profile's should be able
On Mon, Aug 29, 2005 at 05:43:35PM -0400, Chris Gianelloni wrote:
Re: not shoving work onto you, complicating your job, etc, I agree,
and actually is what I was getting at in the badly worded section
below
> > > My point is pretty simple,
> > > why should we spend a bunch of time maintaining s
Chris Gianelloni wrote:
On Mon, 2005-08-29 at 17:34 -0400, [EMAIL PROTECTED] wrote:
I think Brian mentioned /etc/portage/profile and other fun portage tricks
to mess with the default profile. If you think the profile shouldn't be
changed then don't make it a mutable option. If you think th
For those of you who like having only a small amount of USE flags
defined in make.conf along with -*, keeping package.use updated (as to
not break --newuse, etc) can be a laborious task (assuming you even
bother in the first place).
Portage isn't supposed to touch users configuration files, so
On Sat, Aug 27, 2005 at 03:42:25AM -0500, Brian Harring wrote:
> Hola all.
>
> Straight to the point, I'm proposing that the following files-
> arch.list
> categories
> use.desc
> use.local.desc
> package.mask
> updates
Addition to this list: thirdpartymirrors .
~harring
pgpvIGSGfwz7G.pgp
Desc
36 matches
Mail list logo
