1 |
On Wednesday 16 April 2003 08:15, Paul de Vrieze wrote: |
2 |
> On Wednesday 16 April 2003 04:43, George Shapovalov wrote: |
3 |
> > Ok, this is shaping up :). |
4 |
> > |
5 |
> > Dave: could you please submit a bug, with a short description of this |
6 |
> > discussion? Otherwise I am afraid this is going to be easily lost.. |
7 |
> |
8 |
> I would like to add that I believe the failure option is best. Further |
9 |
> there is another problem with duplicate packages, that is duplicate |
10 |
> distfile names. This will not work in the current portage. Maybe portage |
11 |
> should use some automatic renaming feature in case of duplicates. Automatic |
12 |
> prefixing of categoryname+packagename to the file should be doable. The |
13 |
> only thing then is that the file unpacking code should first check for the |
14 |
> prefixed filename. Using directories in distfiles (and maybe too in |
15 |
> packages (where every file is in All)) could also solve possible conflicts. |
16 |
> |
17 |
> Paul |
18 |
|
19 |
There are possible name conflicts in /usr/portage/packages/All and |
20 |
/usr/portage/distfiles. I found bug |
21 |
http://bugs.gentoo.org/show_bug.cgi?id=16222 which seems to cover it. I |
22 |
suggest that packages are stored in /usr/portage/hashes/ and given the file |
23 |
name of the hash value. This ensures uniqueness in the "all files" directory. |
24 |
/usr/portage/packages/All can then be removed and symlinks can point directly |
25 |
to the hashes directory. /usr/portage/distfiles can follow the same |
26 |
convention as packages so we have eg. |
27 |
/usr/portage/distfiles/dev-lang/package-x.y.z-r1/ as the base directory for |
28 |
files, with symlinks inside pointing to the unique files used by that |
29 |
package. |
30 |
|
31 |
I don't like the idea of modifying ebuilds. The ebuild writer has to check |
32 |
that every filename they download is unique, and every package has to be |
33 |
unique. Arbitrary renaming of packages causes more problems, when I wrote the |
34 |
medusa ebuild I noted that theres another medusa in gnome.. We don't want to |
35 |
be renaming packages to things like gnome-extra/gnome-medusa or |
36 |
dev-python/medusa-framework when we already have a perfectly good package |
37 |
hierarchy. |
38 |
|
39 |
-- |
40 |
gentoo-dev@g.o mailing list |