Gentoo Archives: gentoo-dev

From: "Tomáš Chvátal" <tomas.chvatal@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Removals reply
Date: Sat, 02 Feb 2013 13:06:00
Message-Id: 2486077.MJZoxPJNTQ@arcarius
In Reply to: Re: [gentoo-dev] Removals reply by Vaeth
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.
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.
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.
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
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...
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 :-)
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?
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).
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)?
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.
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).
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...
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.
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.
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 >
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.
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.


Subject Author
Re: [gentoo-dev] Removals reply William Hubbs <williamh@g.o>