1 |
On Wed, 2004-08-11 at 00:22, Marius Mauch wrote: |
2 |
> On 08/10/04 Chris Gianelloni wrote: |
3 |
> |
4 |
> > I didn't think anything actually used overlays. The emerge glsa was |
5 |
> > being designed to work like "emerge system" or "emerge world". It |
6 |
> > would require a regular "emerge sync" step to work properly... at |
7 |
> > least, that was my understanding. Forgive me if I'm wrong on that. |
8 |
> |
9 |
> Interesting to see people talking about things that aren't completely |
10 |
> implemented yet ;) |
11 |
> At the moment GLSAs reside in $PORTDIR/metadata/glsa and on |
12 |
> http://www.gentoo.org/security/en/glsa, the current code (used by |
13 |
> glsa-check) only looks at the former location. However I've written the |
14 |
> code in a way so that the location can be changed in the same way as |
15 |
> other portage variables (in make.* or on the commandline), so it's not a |
16 |
> problem to change the location in the profile, however you'll have to |
17 |
> find a way to get the GLSAs there. I originally also planned to |
18 |
> implement a way to get the GLSAs directly over http, but that's more |
19 |
> complicated than I thought first (and not very useful for our current |
20 |
> tree anyway). |
21 |
|
22 |
So I was half right... Thanks for filling in the gaps. |
23 |
|
24 |
> > Personally, I think there should be as little change for the user as |
25 |
> > possible. Breaking "emerge sync" is probably not the best way to go |
26 |
> > about it. Causing "emerge sync" to perform a slightly different |
27 |
> > function, though with the same results (getting new ebuilds) is |
28 |
> > probably the way to go. While I doubt we would be using gensync |
29 |
> > directly, it definitely gives us a strong starting point. I am going |
30 |
> > to say that I wouldn't be opposed to using gensync and a separate |
31 |
> > repository, I just think it ends up being overly complex, as if we're |
32 |
> > going to be offering it as an "official" Gentoo release, we should add |
33 |
> > proper support into the tools we already have (portage). Also, using |
34 |
> > portage and emerge sync for updates allows a user to switch to the |
35 |
> > "current" tree with almost no work. |
36 |
> |
37 |
> As for generating a frozen tree I understand that there are basically |
38 |
> two options: a) use our current (changing) tree and only freeze the |
39 |
> versions of packages in the profile or b) create a new tree that |
40 |
> doesn't change at all (maybe even limited to only include supported |
41 |
> packages/versions). The first is easier to implement but has IMO several |
42 |
> problems: |
43 |
> - we can only limit a package to a specific version, but not "remove" a |
44 |
> complete package that we don't want to support (under the assumption |
45 |
> that we're not going to support the whole tree) |
46 |
> - I doubt that a "packages" file with several hundred (or thousand) |
47 |
> entries is someting most developers want to maintain |
48 |
> - As Spider has already mentioned: It doesn't guarantee a definite base |
49 |
> system as the tree (including the profile) can change over time. |
50 |
> |
51 |
> That leaves us with option b): We already offer tarballs of the portage |
52 |
> tree, including the tarballs used to create our releases. People even |
53 |
> have to use them if they want to use GRP. As people already know how to |
54 |
> use them I'd suggest that we use tarballs to provide our frozen tree |
55 |
> (wether we use the existing ones or create special ones is open for |
56 |
> discussion). As this GLEP is looking for a long-term solution we can |
57 |
> probably rely on some portage modifications that will be included in the |
58 |
> version after 2.0.51 that will enhance our `emerge sync` mechanisms |
59 |
> greatly (removing the need for emerge-webrsync and gensync). With these |
60 |
> modifications we can set SYNC to our tarball and offer updates over |
61 |
> rsync/cvs/tarballs/other transport that will be stored in an overlay, |
62 |
> that overlay can then by synced with `emerge --sync updates` ("updates" |
63 |
> is just an example, we can use any name there). |
64 |
> (Anyone interested in the details of the modification see bug 35535). |
65 |
|
66 |
I think the release tarballs are a good start. I'm more than willing to |
67 |
work to make the tarballs to provide what is wanted for the GLEP. |
68 |
|
69 |
I definitely think that what we use for releases should match the frozen |
70 |
tree that coincides with that release. It means there would be only one |
71 |
set of packages to support, which makes things very easy, and as I said, |
72 |
even allows for possible binary updates in the future, if we so desired. |
73 |
|
74 |
-- |
75 |
Chris Gianelloni |
76 |
Release Engineering QA Manager/Games Developer |
77 |
Gentoo Linux |
78 |
|
79 |
Is your power animal a penguin? |