[gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]

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 personally, due to the fact that the files above are 
essentially repository metadata.  Why move them *now* when they've 
been around forever?

Those files should never have been placed there.  They're repository 
specific data (global data for the repo), and do not belong jammed 
into profiles which is a seperate entity.

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 portage installations accessing it.  
Shifting the files now while changes are being made addresses that 
concern, and makes things a bit more logical.

Not surprising, few issues (and ways to deal with it).
For backwards compatability with portage tools, symlinks are needed to 
prevent older portage versions and tools from suddenly being broke; 
just do a relative link to the new location, no complaints from 
portage.  CVS does not play nice with symlinks however- fortunately  
rsync sucks a bit less, so the symlinks would have to be added 
by the rsync regen script (minor to do).

Two scenarios for how this will result in visible issues for people- 
1) CVS users, aka, devs.  Devs *should* be running latest portage, 
   which would know about the shift.  If they're running an older 
   portage version and aren't willing to upgrade, they tag the 
   symlinks themselves.  It's a minor annoyance frankly; assuming they 
   read -dev (like they're suppossed to :P ), they'll know in advance 
   it's coming.
2) users storing their tree on an fs that lacks symlink support.  They 
   ought to be a miniscule minority, but any issues they hit would be 
   addressed by upgrading portage and any portage tools they use that 
   is reliant on those files.  This is the worst case user scenario, 
   but again, it should be effectively non-existant.

Finally, lang.desc I can't find any reference to in portage tools- 
zhen commited it almost 3 years back, and it hasn't been touched 
since.  Unless somebody knows what the heck that file is for, it's a 
good candidate for removal.

I realize this may seem like a minor/stupid change, but it's a matter 
of cleanup getting things a bit more consistant for when portage is 
capable of dealing with more then one $PORTDIR.  
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Kevin F. Quinn]

On 27/8/2005 10:42:25, Brian Harring (ferringb@gentoo.org) 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

Not sure about package.mask.  I thought that was part of the profile,
as different profiles might package.mask separately.  I know I use it
in /etc/profile to postpone updates.

As far as the others are concerned I'd agree they're not profile data.

Kev.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote:
> On 27/8/2005 10:42:25, Brian Harring (ferringb@gentoo.org) 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
> 
> Not sure about package.mask.  I thought that was part of the profile,
> as different profiles might package.mask separately.  I know I use it
> in /etc/profile to postpone updates.

In fact the arch teams use it to mask packages that won't work on a
particular profile/arch. If package.mask is removed from the profiles
directory does it mean we won't be able to do that anymore ?

Cheers,
Ferdy

-- 
      \\|// . . .  o  o o  o  O  O   (   Born to be   )
       o o                           (      FREE      )
+--ooO--O--Ooo-----------------------------------------------+
| Fernando José Pereda Garcimartín - http://www.ferdyx.org   |
| Gentoo Linux Developer - http://dev.gentoo.org/~ferdy      |
| [ ferdy AT ferdyx DOT org ] && [ ferdy AT gentoo DOT org ] |
|     20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4     |
+------------------------------------------------------------+

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

On Sat, Aug 27, 2005 at 01:32:33PM +0200, Fernando J. Pereda wrote:
> On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote:
> > Not sure about package.mask.  I thought that was part of the profile,
> > as different profiles might package.mask separately.  I know I use it
> > in /etc/profile to postpone updates.
> 
> In fact the arch teams use it to mask packages that won't work on a
> particular profile/arch. If package.mask is removed from the profiles
> directory does it mean we won't be able to do that anymore ?

You're masking occurs within the profile itself, not globally.
Global masking usually is for introduction of new ebuilds that need 
testing and shouldn't be hit by normal arch testers (portage early 
release candidates for example); if you're blocking valgrind on arm 
(fex), you *should* be blocking it in profiles/default-linux/arm, not 
profiles/package.mask ;)

If it's profile specified files, relax, not targeted :).
Strictly after getting the global data out of there, and into a 
directory reflecting that data's actual role within the repository, 
and makes sense in a more flexible, non single 
$PORTDIR+$PORTDIR_OVERlAY environment.

Aside from that, see my other email re: the seperate levels of 
filtering :)
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

On Sat, Aug 27, 2005 at 06:38:36AM -0500, Brian Harring wrote:
> You're masking occurs within the profile itself, not globally.
> Global masking usually is for introduction of new ebuilds that need 
> testing and shouldn't be hit by normal arch testers (portage early 
> release candidates for example); if you're blocking valgrind on arm 
> (fex), you *should* be blocking it in profiles/default-linux/arm, not 
> profiles/package.mask ;)
> 
> If it's profile specified files, relax, not targeted :).
> Strictly after getting the global data out of there, and into a 
> directory reflecting that data's actual role within the repository, 
> and makes sense in a more flexible, non single 
> $PORTDIR+$PORTDIR_OVERlAY environment.
> 
> Aside from that, see my other email re: the seperate levels of 
> filtering :)
> ~harring

That clarified it for me :)

Thanks
Ferdy

-- 
      \\|// . . .  o  o o  o  O  O   (   Born to be   )
       o o                           (      FREE      )
+--ooO--O--Ooo-----------------------------------------------+
| Fernando José Pereda Garcimartín - http://www.ferdyx.org   |
| Gentoo Linux Developer - http://dev.gentoo.org/~ferdy      |
| [ ferdy AT ferdyx DOT org ] && [ ferdy AT gentoo DOT org ] |
|     20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4     |
+------------------------------------------------------------+

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote:
> On 27/8/2005 10:42:25, Brian Harring (ferringb@gentoo.org) 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
> 
> Not sure about package.mask.  I thought that was part of the profile,
> as different profiles might package.mask separately.  I know I use it
> in /etc/profile to postpone updates.
Rough filtering stack-
profiles/package.mask
/etc/make.profile/package.mask (incremental through subprofiles)
users package.mask, and users package.unmask

Ordered it in that fashion to show that it's effectively repository 
filtering, profile filtering, user filtering; if you view it as 
seperate entities with filters stacked up (how the rewrite implements 
it), package.mask being repository metadata becomes clear.

Basically, think of it this way; what files/data *must* stay with a 
repository?  If I'm using (say) gentopia ebuilds, the p.mask they use 
is specific to _their_ repository; my official gentoo repository 
should not be p.mask'ing there stuff, it should only affect itself, 
and any repository that is slaved to it (overlays, which aren't stand 
alone).

At least that's what I think :)
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Kevin F. Quinn]

On 27/8/2005 13:34:15, Brian Harring (ferringb@gentoo.org) wrote:

> Rough filtering stack-
> profiles/package.mask
> /etc/make.profile/package.mask (incremental through subprofiles)
> users package.mask, and users package.unmask
> 
> Ordered it in that fashion to show that it's effectively repository 
> filtering, profile filtering, user filtering; if you view it as 
> seperate entities with filters stacked up (how the rewrite implements 
> it), package.mask being repository metadata becomes clear.

Would it make sense to simply relocate the global package.mask
and package.unmask to the base profile from which all profiles
derive (haven't checked that they all do)?

Users's data could be placed in the users profile at
/etc/portage/profile instead of /etc/portage, and the concept of
global package mask/unmask as repository metadata would go away.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

On Sat, Aug 27, 2005 at 03:29:32PM +0200, Kevin F. Quinn wrote:
> On 27/8/2005 13:34:15, Brian Harring (ferringb@gentoo.org) wrote:
> 
> > Rough filtering stack-
> > profiles/package.mask
> > /etc/make.profile/package.mask (incremental through subprofiles)
> > users package.mask, and users package.unmask
> > 
> > Ordered it in that fashion to show that it's effectively repository 
> > filtering, profile filtering, user filtering; if you view it as 
> > seperate entities with filters stacked up (how the rewrite implements 
> > it), package.mask being repository metadata becomes clear.
> 
> Would it make sense to simply relocate the global package.mask
> and package.unmask to the base profile from which all profiles
> derive (haven't checked that they all do)?
No global unmask;
What you're proposing is actually exactly what I'm against; if I 
choose to use my own profile that's not bound to the tree's profile, I 
should still have my repository masked by the global profile.mask 
that's in it.

Shifting it to base profile forces me to either copy the package.mask 
(or symlink it, which isn't possible in remote), or do without it 
(bad, able to hit packages with security holes and stuff that 
shouldn't be used).

repository package.mask is a seperate filter from profile filter.mask, 
basically.

> Users's data could be placed in the users profile at
> /etc/portage/profile instead of /etc/portage, and the concept of
> global package mask/unmask as repository metadata would go away.
global p.mask is a seperate thing from profile specific p.mask, which 
is the basis of me wanting it moved out of there :)
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]

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 portage installations accessing it.  
> Shifting the files now while changes are being made addresses that 
> concern, and makes things a bit more logical.

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/freebsd/alpha/2006.0
hardened/linux/amd64/2006.0/2.4
hardened/freebsd/x86/2006.0
uclibc/linux/mips/2006.0/cobalt
server/linux/x86/2006.0

etc.

> Two scenarios for how this will result in visible issues for people- 
> 1) CVS users, aka, devs.  Devs *should* be running latest portage, 
>    which would know about the shift.  If they're running an older 
>    portage version and aren't willing to upgrade, they tag the 
>    symlinks themselves.  It's a minor annoyance frankly; assuming they 
>    read -dev (like they're suppossed to :P ), they'll know in advance 
>    it's coming.

Many devs use the latest stable versions of packages rather than testing
versions.  I tend to find this to be a good thing as there are often
bugs in particular combinations of package versions that aren't
necessarily spotted when running all ~arch.

Also, devs are not required to read or even be subscribed to -dev.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]

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/freebsd/alpha/2006.0
> hardened/linux/amd64/2006.0/2.4
> hardened/freebsd/x86/2006.0
> uclibc/linux/mips/2006.0/cobalt
> server/linux/x86/2006.0

I like...
That's pretty much what I'm aiming for; not after forcing *you* to do 
server/etc, just would prefer to see it structured so that others can 
do so.

That said, initial email was worded a bit strongly, so pardon ;)

> > Two scenarios for how this will result in visible issues for people- 
> > 1) CVS users, aka, devs.  Devs *should* be running latest portage, 
> >    which would know about the shift.  If they're running an older 
> >    portage version and aren't willing to upgrade, they tag the 
> >    symlinks themselves.  It's a minor annoyance frankly; assuming they 
> >    read -dev (like they're suppossed to :P ), they'll know in advance 
> >    it's coming.
> 
> Many devs use the latest stable versions of packages rather than testing
> versions.  I tend to find this to be a good thing as there are often
> bugs in particular combinations of package versions that aren't
> necessarily spotted when running all ~arch.
> 
> Also, devs are not required to read or even be subscribed to -dev.

Agreed.  Implicit in all this is that I'm going to have to make a bit 
of noise (and probably attempt and get it shoved out via gwn) prior to 
doing it, so that I don't have ~100 devs who didn't hear the news 
looking in my direction.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]

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 give us something like this:
> > 
> > default/linux/x86/2006.0
> > default/freebsd/alpha/2006.0
> > hardened/linux/amd64/2006.0/2.4
> > hardened/freebsd/x86/2006.0
> > uclibc/linux/mips/2006.0/cobalt
> > server/linux/x86/2006.0
> 
> I like...
> That's pretty much what I'm aiming for; not after forcing *you* to do 
> server/etc, just would prefer to see it structured so that others can 
> do so.

I might just go ahead and do this (at least the default/linux part) for
2006.0, so we can slowly transition away from the default-linux stuff as
we deprecate older profiles.

> That said, initial email was worded a bit strongly, so pardon ;)

No problem... it happens when one speaks of something they're passionate
about.

> > > Two scenarios for how this will result in visible issues for people- 
> > > 1) CVS users, aka, devs.  Devs *should* be running latest portage, 
> > >    which would know about the shift.  If they're running an older 
> > >    portage version and aren't willing to upgrade, they tag the 
> > >    symlinks themselves.  It's a minor annoyance frankly; assuming they 
> > >    read -dev (like they're suppossed to :P ), they'll know in advance 
> > >    it's coming.
> > 
> > Many devs use the latest stable versions of packages rather than testing
> > versions.  I tend to find this to be a good thing as there are often
> > bugs in particular combinations of package versions that aren't
> > necessarily spotted when running all ~arch.
> > 
> > Also, devs are not required to read or even be subscribed to -dev.
> 
> Agreed.  Implicit in all this is that I'm going to have to make a bit 
> of noise (and probably attempt and get it shoved out via gwn) prior to 
> doing it, so that I don't have ~100 devs who didn't hear the news 
> looking in my direction.

What other changes are you guys thinking of regarding profiles?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]

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 to be just plugged in; I 
don't care to bite off any more then I already have ;)

Offhand, I'd expect the removal of package filtering in the packages 
files (package.mask provides this already), probably a bit of renaming 
of packages also.

Why?  Packages is vague.  Stupid reason to change it I realize, but 
packages makes sense in a single set, 'system' set view.  Rearrange it 
so that packages isn't auto assumed to be system, stick it in a subdir 
fex, and you would give profiles the capability to arbitrarily define 
their own sets.

Aside from that, the parent implementation could stand a tweak or two.  
Further, assuming metapkg goes through, virtual is obsoleted.  The 
inclusion of GRP_STAGE23_USE also bugs me a bit; yes it works right 
now, but what happens when you need to push more info in?  Seems like 
it should be contained on it's own.

Either way, just a couple of things off the top of my head.  My main 
push for it is cleanup for stand alone repositories, and ensuring 
anything people attempt with profiles doesn't have side effects on the 
raw repositories metadata.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On Mon, 2005-08-29 at 17:24 -0500, Brian Harring wrote:
> Aside from that, the parent implementation could stand a tweak or two.  
> Further, assuming metapkg goes through, virtual is obsoleted.  The 
> inclusion of GRP_STAGE23_USE also bugs me a bit; yes it works right 
> now, but what happens when you need to push more info in?  Seems like 
> it should be contained on it's own.

Actually, we've dumped GRP_STAGE23_USE in catalyst and decided that it
was better to keep everything consistent across the board and just
include everything in USE and use it instead.  You won't see
GRP_STAGE23_USE in any new profiles.

> Either way, just a couple of things off the top of my head.  My main 
> push for it is cleanup for stand alone repositories, and ensuring 
> anything people attempt with profiles doesn't have side effects on the 
> raw repositories metadata.

Ahh... so nothing really crazy or divergent from what we have now, just
generally making them cleaner and more sane.  I'm definitely behind that
100%.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

On Tue, 2005-08-30 at 01:03 -0500, Brian Harring wrote:
> 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 .

Question about thirdpartymirrors (this is for everyone, not just
Brian)...

What is the preferred method for listing mirrors, just listing the site
name, or listing the site name plus path to the particular item?

The reason that I ask is the 3dgamers mirror rotation could have the
paths added to it, which would actually shorten a lot of SRC_URI's in
quite a few games ebuilds.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Marius Mauch]

On 08/30/05  Chris Gianelloni wrote:

> On Tue, 2005-08-30 at 01:03 -0500, Brian Harring wrote:
> > 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 .
> 
> Question about thirdpartymirrors (this is for everyone, not just
> Brian)...
> 
> What is the preferred method for listing mirrors, just listing the
> site name, or listing the site name plus path to the particular item?
> 
> The reason that I ask is the 3dgamers mirror rotation could have the
> paths added to it, which would actually shorten a lot of SRC_URI's in
> quite a few games ebuilds.

IMO use the longest path that works for all ebuilds using that mirror
entry.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Francesco R]

Chris Gianelloni wrote:

>On Tue, 2005-08-30 at 01:03 -0500, Brian Harring wrote:
>  
>
>>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 .
>>    
>>
>
>Question about thirdpartymirrors (this is for everyone, not just
>Brian)...
>
>What is the preferred method for listing mirrors, just listing the site
>name, or listing the site name plus path to the particular item?
>  
>
example from mysql mirrors:

ftp://mirror.mcs.anl.gov/pub/mysql
http://mirror.sit.wisc.edu/mysql
http://mysql.orst.edu

The mirror item should be the minimum common denominator between the
mirrors. In this specific case because the mirror is usable also for
other products of mysql.

>The reason that I ask is the 3dgamers mirror rotation could have the
>paths added to it, which would actually shorten a lot of SRC_URI's in
>quite a few games ebuilds.
>
>  
>
there are always excepitions ;-) You are speaking of paths that will
*never* change right ?


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Marius Mauch]

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 personally, due to the fact that the
> files above are  essentially repository metadata.  Why move them *now*
> when they've  been around forever?

[snip]

Don't mind moving them, BUT
- metadata is a stupid location for them for several reasons
- don't really like adding more cruft to the regen script
- why move them now and then move/redesgin them again when someone
finally makes a sane profiles design (yeah, I've talked about that for
months now :-/)

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

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 directory in the tree, and into the
> > existing  metadata directory personally, due to the fact that the
> > files above are  essentially repository metadata.  Why move them *now*
> > when they've  been around forever?
> 
> [snip]
> 
> 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, pregenerated cache, glsa set...
It holds global metadata for the repository.

> - don't really like adding more cruft to the regen script
Agreed.  That said, users bitching when the don't upgrade their tools, 
and said tools start breaking isn't fun.

> - why move them now and then move/redesgin them again when someone
> finally makes a sane profiles design (yeah, I've talked about that for
> months now :-/)
Anyone after redesigning profiles has their hands full.  Do this 
change now, profile redesign isn't burdened with dealing with this 
mess.  This change over as indicated in other postings to this thread 
also would prepare for allowing full capabilities to standalone 
repositories, rather then coming up with a hack that pulls the data 
from profiles.

The change over can be done pretty cleanly, and organizes stuff as it 
should be, in preparation of upcoming tweaks/capabilities/whatever.

I'd rather nip this now, rather then when it starts creating problems 
down the line.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Marius Mauch]

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, pregenerated cache, glsa set...
> It holds global metadata for the repository.

a) doesn't exist in CVS
b) is generally associated with "populated by cvs->rsync"
c) becomes just another dumping ground (it should only hold the cache
IMO)
d) This isn't "metadata" at all

Name it "misc" or "global" or some other non-existing-dir.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

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 holds global repository information, time of 
> > repositories generation, pregenerated cache, glsa set...
> > It holds global metadata for the repository.
> 
> a) doesn't exist in CVS
Not an arguement against it, since any other directory must also be 
added.

> b) is generally associated with "populated by cvs->rsync"
Only by those who deal in cvs; minority I might add.

> c) becomes just another dumping ground (it should only hold the cache
> IMO)
Whatever directory gets added, suffers the same potential.  Regarding 
the cache, see below.

> d) This isn't "metadata" at all
The repository is a container of data; the files targeted are data 
about the repository data.

That's the exact definition of metadata, data about data.

What's the pregenerated cache, or moreso, what's the cache?  data 
lifted from ebuilds (build data).  The naming is apt.

Storing the repository metadata in a common directory also makes sense 
if you consider the fact that people sharing their own repository 
*may* be distributing a pregenerated cache alongside; it's data that's 
bound to the specific layout of our current form of ebuild repository.

So... I'm not seeing how this is anything but the right location for 
it.  global is a fitting name if it's a global template for ebuilds, 
something that is directly used in all ebuilds.  These files aren't, 
they're strictly a higher layer of data/descriptions for the data 
ebuilds group hold/export (p.mask breaks down on this, but it's the 
sole exception nearest I can figure).
~harring


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir

[Marius Mauch]

On 08/29/05  Brian Harring wrote:

> 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 holds global repository information, time of 
> > > repositories generation, pregenerated cache, glsa set...
> > > It holds global metadata for the repository.
> > 
> > a) doesn't exist in CVS
> Not an arguement against it, since any other directory must also be 
> added.

Was more about "exists in rsync, but not in CVS". Anyway, see below.

> > b) is generally associated with "populated by cvs->rsync"
> Only by those who deal in cvs; minority I might add.
> 
> > c) becomes just another dumping ground (it should only hold the
> > cache IMO)
> Whatever directory gets added, suffers the same potential.  Regarding 
> the cache, see below.

Sure, but then lets give it an appropriate name.

> > d) This isn't "metadata" at all
> The repository is a container of data; the files targeted are data 
> about the repository data.
> 
> That's the exact definition of metadata, data about data.

Ah, now I can see where you're coming from, even though I still have to
disagree. IMO the metadata dir is meant to contain *package* metadata,
also I don't consider the mentioned files for the most part metadata but
actually properties of the repo.
But even ignoring that, I still think it's a very bad idea to mix
generated and non-generated stuff in the same dir. In my experience that
often results in problems. That's my main issue.

> What's the pregenerated cache, or moreso, what's the cache?  data 
> lifted from ebuilds (build data).  The naming is apt.

Did I ever disagree with that?

> Storing the repository metadata in a common directory also makes sense

Agreed, see above though.

> if you consider the fact that people sharing their own repository 
> *may* be distributing a pregenerated cache alongside; it's data that's
> bound to the specific layout of our current form of ebuild repository.

What has that to do with anything here?

> So... I'm not seeing how this is anything but the right location for 
> it.  global is a fitting name if it's a global template for ebuilds, 
> something that is directly used in all ebuilds.  These files aren't, 
> they're strictly a higher layer of data/descriptions for the data 
> ebuilds group hold/export (p.mask breaks down on this, but it's the 
> sole exception nearest I can figure).

global == affects/represents all packages in the repo

Btw, I'm not sure you can consider the profiles independent of the repo
(which I think is one thing you're after with this move). I've thought
about it in the past too, but in the end they are tied to the repo (use
flags, archs, cpv instances, ...). Not an argument against the move,
just something to consider down the road.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
-- 
gentoo-dev@gentoo.org mailing list