1 |
Dne So 2. února 2013 12:44:30, Vaeth napsal(a): |
2 |
> |
3 |
> When I came to Gentoo many years ago, this was a very rare problem, |
4 |
> but the removal of packages has tremendously increased, and it is |
5 |
> not only me who is observing this problem - there were already some |
6 |
> threads in the forums, and people planning to but not coming back |
7 |
> to Gentoo for this reason. |
8 |
|
9 |
Awesome so they could've get involved and maintain it themselves if they seen |
10 |
it so crushial for their lives. |
11 |
When looking on Robins automated packages addition/removal tracker it seems |
12 |
that the removal trend does not change much, the only thing that changed is |
13 |
that now with tinderbox we see way earlier that package is broken to build and |
14 |
thus removed rather than being in tree uninstallable. Also on the additions |
15 |
side we are quite getting more and more stuff in tree. |
16 |
|
17 |
> |
18 |
> > Also there is proposal to create git repository with patches exactly for |
19 |
> > this purposes. |
20 |
> |
21 |
> This might solve the problem of the patches but not of the lost tarballs. |
22 |
> |
23 |
> It was suggested in this thread to put up some server with the |
24 |
> tarballs. This might be a solution, but for such "isolated" solutions |
25 |
> there is always the danger that the same could happen as did once to |
26 |
> the Gentoo Wiki: It would be better if the old tarballs are also on |
27 |
> the mirrors (at least on some of them); maybe one could make some |
28 |
> "optional" directory which not every mirror is supposed to have. |
29 |
|
30 |
As I said in my first mail, distro mirroring system is not to pose for |
31 |
upstream. You have to set up some webpage and download on some site. I |
32 |
mentioned fedorahosted because that one is managed by rh so it won't diappear, |
33 |
but you can put it on github or elsewhere if you feel like it. |
34 |
> |
35 |
> > You still can count the packages using huge patchsets using just your |
36 |
> > hands. |
37 |
> |
38 |
> Again, the number is not so important, but "counting by using your hands" |
39 |
> I did not expect to be meant binary ;) |
40 |
> |
41 |
> %grep -l "http.*:.*patch.*\..*z.*" /srv/portage/gentoo/*/*/*.ebuild|wc -l |
42 |
> 421 |
43 |
Yay, now lets see what are biggest consumers on your list: |
44 |
kernel, coreutils, netbeans, postgres |
45 |
|
46 |
Sweet this leaves around 200 versioned ebuilds with 2 versions in tree each. |
47 |
So 100 not critical ebuids of all the in-tree ebuilds use custom patchsets... |
48 |
|
49 |
I agree that we should track the patches in some git repository so feel free |
50 |
to open bugreport for infra team to fire up some structure that everyone will |
51 |
be required to use. Also thinking about it we still have this nice policy |
52 |
where we should open upstream bugreports and contribute all patches back, so |
53 |
they should in theory be always somewhere else too :-) |
54 |
|
55 |
> |
56 |
> > so we can say someone get hardware that |
57 |
> > is at least decade old, honestly just obtain distros build around |
58 |
> > such HW (like debian stable). |
59 |
> |
60 |
> Gentoo is about choice. I bet, many Gentoo users have at least some old |
61 |
> hardware device which they want to use. Maybe occasionally, they also |
62 |
> inherit some which they want to use. You really want to scare all |
63 |
> these users away? |
64 |
|
65 |
Yes gentoo is about choice but the choice does not mean to contain everything |
66 |
possible in the tree. We keep the tree maintainable and working for everyone, |
67 |
it is not just some junkyard of whatever did compile few years back for lucky |
68 |
people. |
69 |
Actually suse/fedora and others remove packages way more than us, they just do |
70 |
it with each release so it does not happen here and there but just once every |
71 |
6 months (or whatever is their release cycle). |
72 |
|
73 |
> |
74 |
> >> Or if he was not yet a gentoo user at the time when the package was |
75 |
> >> removed (or absent/busy for a long period)? |
76 |
> > |
77 |
> > Well he would found out after sync |
78 |
> |
79 |
> Perhaps there was a misunderstanding: |
80 |
> How can someone who starts to use Gentoo in a year find out after sync? |
81 |
> Or another one know a year in advance that he will have the need for some |
82 |
> special software (e.g. to support a device which he inherits in a year)? |
83 |
|
84 |
So when he starts using Gentoo he can look up if the sw he needs is supported |
85 |
and go elsewhere if it is not, or actually contribute and do some stuff about |
86 |
it to make it work for himself. |
87 |
Basically our goal is to create good distribution for us. There is no goal to |
88 |
dominate market or something like that. Take a look on ubuntu, tons of people |
89 |
are using it but it does not help the development team because not much of |
90 |
those contribute back. We rather preffer people that actually can and |
91 |
contribute back. When looking on our stats the user counts seem quite same so |
92 |
we are not losing any user share lately, but on contributors side seems like |
93 |
people are just consuming than contributing back. And contributors are the |
94 |
only ones that are important as they help you in our job. |
95 |
|
96 |
> |
97 |
> > Gentoo is not a distro with bigger resources |
98 |
> |
99 |
> I agree: If none of the developers is interested in a package, |
100 |
> it is completely fine to declare it as unsupported and to require the |
101 |
> user to maintain it himself (or hire somebody) if he wants to use it. |
102 |
> |
103 |
> Masking it is perfectly fine |
104 |
> (maybe another idea would be to introduce some new "state" for such |
105 |
> unmaintained packages so that they are usually ignored). |
106 |
|
107 |
As I said above, cvs tree is not junkyard of something that used to work, so |
108 |
keeping stuff around and masked is actually burden for us, where you as user |
109 |
interested in the package should care. We have to track bugs and react on |
110 |
those even for the masked packages... |
111 |
|
112 |
> |
113 |
> I just ask that Gentoo should not *hinder* the user in installing/ |
114 |
> maintaining a package later by removing the tarballs (and possibly |
115 |
> patches) which once were available. |
116 |
|
117 |
Managing tarballs is upstreams job, if that dies you can still try to get it |
118 |
from rpm/deb packages if such are around. If not then probably nobody ever |
119 |
cared that much, so seek alternative tools for your job. We lack the tool for |
120 |
the patchsets only and that is for infra to solve. But see above what I wrote |
121 |
about the patches, they must be somewhere if maintainer didn't slack and |
122 |
adhere to the policy. |
123 |
|
124 |
> |
125 |
> If these mild (essentially only storage) resources are *really* a severe |
126 |
> issue for Gentoo (or uninstalled masked packages should cause a |
127 |
> considerable slowdown for portage's resolver) then Gentoo has a much |
128 |
> more severe resources problem (or technical problem with portage)... |
129 |
> |
130 |
|
131 |
No distribution does archive tarballs for upstream that was removed. The |
132 |
problem is that it stays around for a bit longer in the release based distros |
133 |
as they have some 1-2 year maintenance cycle for which they keep repos around. |
134 |
But when this point is hit everything disappears. There is no purpose in |
135 |
wasting storage/bandwidth to mirror stuff that is marked obsolete. |
136 |
|
137 |
Btw did any of you guys look on how much packages were removed just for being |
138 |
dead upstream? They usually have to became maintenance nightmare too before |
139 |
they are pruned. I myself didn't check that out but I bet it will be not that |
140 |
much of the removals. Most of them just have some running web page and they |
141 |
just simply don't build and nobody wanted to fix them. |