1 |
I've been using my own rsync mirror for my handful of Gentoo boxes, and |
2 |
for a long time I've been lusting after something like tagged branches |
3 |
of the Portage tree like how you have Woody or Slink or Sarge in Debian, |
4 |
or how you have -CURRENT, -STABLE, -RELENG_N_M in FreeBSD. |
5 |
|
6 |
This discussion has come up a few times on this list before, in short |
7 |
form. It sounds like the core Gentoo team is busier with other things, |
8 |
and the zeitgeist is that people like us would just use the GRP. |
9 |
|
10 |
I'd LOVE to start/work on some sort of project to maintain different |
11 |
Portage trees for people to rsync against. I think it could work out |
12 |
really well, it'd be a symbiotic relationship to the current Gentoo - |
13 |
the herd of Gentoo developers can continue advancing the distro, adding |
14 |
bleeding edge ebuilds to Portage, etc. Basically, advancing the Gentoo |
15 |
analogue of sid/-CURRENT. Then the other Portage Branches project can |
16 |
siphon off the ebuilds they want and apply their own pessimism to create |
17 |
stable branches, versioned releases of the tree and so on. Then people |
18 |
pick the branch they want to sync against, and use it. |
19 |
|
20 |
I wrote a short rant about it here: |
21 |
http://branched.modestolan.com |
22 |
|
23 |
On Mon, 18 Aug 2003 09:27:36 +1000 |
24 |
Ron O'Hara <rono@×××××××××××.au> wrote: |
25 |
|
26 |
> Having your own rsync mirror is only really like having a single extra |
27 |
> |
28 |
> 'tag'... although it does address the issue of ebuilds that disappear. |
29 |
> |
30 |
> (so does /usr/local/portage) |
31 |
> The other deficiency with running your own rsyncmirror is just that |
32 |
> it's effectively a private 'fork' - that pushes lots of the |
33 |
> maintenance issues back into your own lap. A primary benefit of using |
34 |
> any 'distro' is that a bigger team is keeping an eye on all the |
35 |
> changes going on. With a commercially backed distro like RedHat you |
36 |
> are hoping that they have the financial resources to keep on |
37 |
> supporting that distro and creating RPMS to match the old releases. |
38 |
> You also have a defined statement about how long a particular old |
39 |
> release is supported. |
40 |
> |
41 |
> Personally, I prefer the open source community approach for real |
42 |
> guarantees that support will continue -even if I need to do a little |
43 |
> bit of it myself on behalf of the community - and this is a different |
44 |
> issue from the idea of supporting 'tags' against the emerge sync. The |
45 |
> |
46 |
> community (collectively) has more resources than any individual or |
47 |
> company. |
48 |
> |
49 |
> You are also right that removing 'old' files from portage is an |
50 |
> issue... in fact probably a show stopper in some instances. Perhaps |
51 |
> the solution is to look at it as if the portage tree is under CVS |
52 |
> control. That would make the unstable "~arch" stuff associated with |
53 |
> the HEAD of the tree. You would need a label to identify the |
54 |
> equivelant of the 'stable' branch. Other labels would represent the |
55 |
> 'tag's available for using with emerge sync. |
56 |
> In this style of setup, old ebuilds are not 'deleted' - just removed |
57 |
> from the stable and HEAD parts of the tree. IE. They still exists |
58 |
> within the 'tag' that represents the historical development of gentoo. |
59 |
> They are no longer maintained, but are still part of an 'old release' |
60 |
> (or tag)(I'm really thinking of it more in terms of a Clearcase style |
61 |
> version control file system where a user has a 'view' of the files at |
62 |
> a particular point in time on a particular branch of development - |
63 |
> maybe use http://www.gnu.org/directory/sysadmin/vc/cvsfs.html ???) |
64 |
> |
65 |
> The associated space and bandwidth issues for mirror sites can be |
66 |
> addressed by only mirroring the HEAD and 'stable' parts - this is the |
67 |
> same as the current level. |
68 |
> |
69 |
> |
70 |
> It then becomes easy to implement a policy for support of 'back |
71 |
> releases' - you could just choose something like - "gentoo maintains |
72 |
> four years worth of tagged versions." Not only that, if any company |
73 |
> wants to have a longer timeframe supported, then they only need to |
74 |
> offer disk space and bandwidth support to achieve this - or THEN run |
75 |
> their own rsync mirror. |
76 |
> Since gentoo is a source level distro, many of the hassles that |
77 |
> RedHat, Mandrake etc have making RPMS for old releases dont apply. |
78 |
> |
79 |
> I'm NOT implying developer support for 'old' ebuilds - but if package |
80 |
> 'xzy' used to be available with Gentoo in Aug2002, it should still be |
81 |
> available when you are building a system at that version level. This |
82 |
> would also mean that if someone really must have it supported - then |
83 |
> they can do it themselves and get it moved back into the main branch. |
84 |
> If this 'tag' idea makes it attactive for companies to use Gentoo, |
85 |
> then I would expect an explosion in the number of active (company |
86 |
> paid) developers maintaining the ebuilds of little programs that the |
87 |
> core team could not justify supporting. |
88 |
> |
89 |
> |
90 |
> Another thing that running your own rsync mirror can never achieve is |
91 |
> third party vendor certification. Having defined 'tags' would allow |
92 |
> companies like Oracle to certify a particular version of Gentoo as |
93 |
> being supported. Thats not currently possible. The very power and |
94 |
> flexibility that Gentoo gives developers is also totally incompatible |
95 |
> with the major software vendor QA techniques. Using a 'tag' would go a |
96 |
> long way to overcoming this. |
97 |
> It would become possible for people like SAP to certify their products |
98 |
> |
99 |
> as supported with specific 'make.conf' settings for a specific tag. |
100 |
> Thats enough to make Gentoo fine for both the Quality Assured type |
101 |
> large deployment and yet still retain brilliant upgrade and security |
102 |
> patch capabilities. |
103 |
> |
104 |
> Cheers |
105 |
> Ron |
106 |
> |
107 |
> > |
108 |
> >Tbh, it's a hack, rather than a nice solid server/client |
109 |
> >enterprise-ready Portage solution, but it's one that does work. |
110 |
> > |
111 |
> >Best regards, |
112 |
> >Stu |
113 |
> > |
114 |
> > |
115 |
> |
116 |
> |
117 |
> |
118 |
> -- |
119 |
> gentoo-dev@g.o mailing list |
120 |
> |
121 |
> |
122 |
|
123 |
|
124 |
|
125 |
-- |
126 |
gentoo-dev@g.o mailing list |