1 |
W dniu sob, 27.01.2018 o godzinie 11∶36 +0000, użytkownik Roy Bamford |
2 |
napisał: |
3 |
> On 2018.01.27 08:30, Michał Górny wrote: |
4 |
> > W dniu pią, 26.01.2018 o godzinie 20∶48 -0500, użytkownik Michael |
5 |
> > Orlitzky napisał: |
6 |
> > > On 01/26/2018 06:24 PM, Michał Górny wrote: |
7 |
> > > > |
8 |
> > > > The alternate option of using file hash has the advantage of |
9 |
> > |
10 |
> > having |
11 |
> > > > a more balanced split. Furthermore, since hashes are stored |
12 |
> > > > in Manifests using them is zero-cost. However, this solution has |
13 |
> > |
14 |
> > two |
15 |
> > > > significant disadvantages: |
16 |
> > > > |
17 |
> > > > 1. The hash values are unknown for newly-downloaded distfiles, so |
18 |
> > > > ``repoman`` (or an equivalent tool) would have to use a |
19 |
> > |
20 |
> > temporary |
21 |
> > > > directory before locating the file in appropriate subdirectory. |
22 |
> > > > |
23 |
> > > > 2. User-provided distfiles (e.g. for fetch-restricted packages) |
24 |
> > |
25 |
> > with |
26 |
> > > > hash mismatches would be placed in the wrong subdirectory, |
27 |
> > > > potentially causing confusing errors. |
28 |
> > > > |
29 |
> > > |
30 |
> > > The filename proposal sounds fine, so this is only academic, but: |
31 |
> > |
32 |
> > are |
33 |
> > > these two points really disadvantages? |
34 |
> > > |
35 |
> > > What are we worried about in using a temporary directory? Copying |
36 |
> > |
37 |
> > across |
38 |
> > > filesystem boundaries? Except in rare cases, $DISTDIR itself will be |
39 |
> > > usable a temporary location (on the same filesystem), won't it? |
40 |
> > |
41 |
> > Why add the extra complexity when there's no need for one? Note that |
42 |
> > there's also the problem of resuming transfers, so in the end we're |
43 |
> > talking about permanent temporary directory where we keep unfinished |
44 |
> > transfers. |
45 |
> > |
46 |
> > > For the second point, portage is going to tell me where to put the |
47 |
> > |
48 |
> > file, |
49 |
> > > isn't it? Then no matter what garbage I download, won't portage look |
50 |
> > |
51 |
> > for |
52 |
> > > it in the right place, because where-to-put-it is determined using |
53 |
> > |
54 |
> > the |
55 |
> > > same manifest hash that determines where-to-find-it? |
56 |
> > |
57 |
> > No, it won't. Why would it? You're going to call something like: |
58 |
> > |
59 |
> > edistadd foo.tar.gz bar.tar.gz |
60 |
> > |
61 |
> > ...and it will place the files in the right subdirectories. |
62 |
> > |
63 |
> > -- |
64 |
> > Best regards, |
65 |
> > Michał Górny |
66 |
> > |
67 |
> > |
68 |
> > |
69 |
> > |
70 |
> |
71 |
> Michał, |
72 |
> |
73 |
> How does this work for fetch restricted files and finding other files |
74 |
> no longer on the mirrors? |
75 |
> |
76 |
> Its no longer a download and move it to $DISTFILES, or is it? |
77 |
> Whatever it is, users will need to do it unless files in $DISTFILES |
78 |
> are accepted by package managers if they are not found in the main |
79 |
> structure. |
80 |
|
81 |
I've just answered that, and it's in the GLEP also. There will be |
82 |
a helper tool to make this easy. Furthermore, I think we may even make |
83 |
Portage keep accepting both locations indefinitely. |
84 |
|
85 |
As for finding files in your distdir, there's no reason why plain: |
86 |
|
87 |
find -name 'foo.tar.gz' |
88 |
|
89 |
wouldn't work. |
90 |
|
91 |
-- |
92 |
Best regards, |
93 |
Michał Górny |