On Mon, 6 Mar 2006 13:45:01 -0500,
Daniel Ostrow [EMAIL PROTECTED] wrote:
portage will need to know that the location, on the distfiles
mirrors, of cronolog, is now the equivilent of
mirror://gentoo/${firstchar}
And what about the local mirror type, that one can define in
Hi,
as suggested by Mike in http://bugs.gentoo.org/show_bug.cgi?id=123335,
here's my proposal for changing the layout of the distfiles tree:
This is the current state:
mirror:/storage/gentoo/data/source/distfiles# ls | wc -l
22543
mirror:/storage/gentoo/data/source/distfiles# ls -l ../ |
Michael Renner wrote:
Hi,
as suggested by Mike in http://bugs.gentoo.org/show_bug.cgi?id=123335,
here's my proposal for changing the layout of the distfiles tree:
Introducing an additional directory hierarchy should fix this, and is
the common solution for this problem for various
Alec Warner wrote:
Is this plan for server side only distfiles, or do you want
/usr/portage/distfiles/{a-z}/ on the local system as well.
Changing the layout on the server suffices, no need to fiddle around
with more scripts than necessary ;).
Is there any needed performance benefit out
Kurt Lieber wrote:
If we can come up with a seamless, painless transition process, great,
let's make it happen.
From the _MIRROR_-side using hardlinks should be fine enough, we'd just
have to ensure that every mirror uses -H (preserve hardlinks). And for
the mirrors not using -H this will
Michael Renner wrote:
Kurt Lieber wrote:
If we can come up with a seamless, painless transition process, great,
let's make it happen.
From the _MIRROR_-side using hardlinks should be fine enough, we'd just
have to ensure that every mirror uses -H (preserve hardlinks). And for
the
Alec Warner wrote:
Taking the earlier comment ( changing files only on the mirrors ) there
are no portage changes that are technically required. However, you'd
need to change about 1 ( random number I pulled out of my ass, but
there are many affected ) SRC_URI's to point to the new
On Monday 06 March 2006 12:36, Alec Warner wrote:
Michael Renner wrote:
Kurt Lieber wrote:
If we can come up with a seamless, painless transition process, great,
let's make it happen.
From the _MIRROR_-side using hardlinks should be fine enough, we'd just
have to ensure that every
Daniel Ostrow wrote:
Hrm, /me thinks you are missing something there, almost the entire tree
doesn't explicitly state the mirror://gentoo SRC_URI, portage handles that
automatically. That being the case portage would have change so that the
automatic lookup was mirror://gentoo/${firstchar}/.
Simon Stelling wrote:
Alec Warner wrote:
Taking the earlier comment ( changing files only on the mirrors )
there are no portage changes that are technically required. However,
you'd need to change about 1 ( random number I pulled out of my
ass, but there are many affected ) SRC_URI's
On Monday 06 March 2006 13:18, Simon Stelling wrote:
Daniel Ostrow wrote:
Hrm, /me thinks you are missing something there, almost the entire tree
doesn't explicitly state the mirror://gentoo SRC_URI, portage handles
that automatically. That being the case portage would have change so that
Simon Stelling wrote:
Daniel Ostrow wrote:
Hrm, /me thinks you are missing something there, almost the entire
tree doesn't explicitly state the mirror://gentoo SRC_URI, portage
handles that automatically. That being the case portage would have
change so that the automatic lookup was
Hi,
On 3/6/06, Michael Renner [EMAIL PROTECTED] wrote:
Hi,
as suggested by Mike in http://bugs.gentoo.org/show_bug.cgi?id=123335,
here's my proposal for changing the layout of the distfiles tree:
Introducing an additional directory hierarchy should fix this, and is
the common solution for
Stuart Herbert wrote:
Why not have the directory structure follow the package category
structure? E.g. the distfiles for package foo/bar goes into the
directory ${MIRROR_ROOT}/foo/bar?
This should be easy enough to support in Portage, and if applied to
the /usr/portage/distfiles directory too,
Alin Nastac wrote:
this has been discussed before.
summary: tarballs could be used by more than one package. this way
you'll manage to increase the disk space demands for our mirrors.
This one is about sorting by first letter of filename. It won't solve
multiple different files with same
On 3/6/06, Alin Nastac [EMAIL PROTECTED] wrote:
this has been discussed before.
summary: tarballs could be used by more than one package. this way
you'll manage to increase the disk space demands for our mirrors.
And you can't hard-link the files into multiple directories because ...?
Best
Michael Renner wrote:
Introducing an additional directory hierarchy should fix this, and is
the common solution for this problem for various projects, be it debian
[1], cpan [2], slackware [3], etc.
One migration scenario for a better future:
Create subdirectories named after the first
On Mon, 6 Mar 2006 19:54:28 + Stuart Herbert
[EMAIL PROTECTED] wrote:
| On 3/6/06, Alin Nastac [EMAIL PROTECTED] wrote:
| this has been discussed before.
| summary: tarballs could be used by more than one package. this way
| you'll manage to increase the disk space demands for our mirrors.
Jan Kundrát wrote:
Alin Nastac wrote:
this has been discussed before.
summary: tarballs could be used by more than one package. this way
you'll manage to increase the disk space demands for our mirrors.
This one is about sorting by first letter of filename. It won't solve
multiple
19 matches
Mail list logo
