Dne So 2. února 2013 12:44:30, Vaeth napsal(a): > > When I came to Gentoo many years ago, this was a very rare problem, > but the removal of packages has tremendously increased, and it is > not only me who is observing this problem - there were already some > threads in the forums, and people planning to but not coming back > to Gentoo for this reason.
Awesome so they could've get involved and maintain it themselves if they seen it so crushial for their lives. When looking on Robins automated packages addition/removal tracker it seems that the removal trend does not change much, the only thing that changed is that now with tinderbox we see way earlier that package is broken to build and thus removed rather than being in tree uninstallable. Also on the additions side we are quite getting more and more stuff in tree. > > > Also there is proposal to create git repository with patches exactly for > > this purposes. > > This might solve the problem of the patches but not of the lost tarballs. > > It was suggested in this thread to put up some server with the > tarballs. This might be a solution, but for such "isolated" solutions > there is always the danger that the same could happen as did once to > the Gentoo Wiki: It would be better if the old tarballs are also on > the mirrors (at least on some of them); maybe one could make some > "optional" directory which not every mirror is supposed to have. As I said in my first mail, distro mirroring system is not to pose for upstream. You have to set up some webpage and download on some site. I mentioned fedorahosted because that one is managed by rh so it won't diappear, but you can put it on github or elsewhere if you feel like it. > > > You still can count the packages using huge patchsets using just your > > hands. > > Again, the number is not so important, but "counting by using your hands" > I did not expect to be meant binary ;) > > %grep -l "http.*:.*patch.*\..*z.*" /srv/portage/gentoo/*/*/*.ebuild|wc -l > 421 Yay, now lets see what are biggest consumers on your list: kernel, coreutils, netbeans, postgres Sweet this leaves around 200 versioned ebuilds with 2 versions in tree each. So 100 not critical ebuids of all the in-tree ebuilds use custom patchsets... I agree that we should track the patches in some git repository so feel free to open bugreport for infra team to fire up some structure that everyone will be required to use. Also thinking about it we still have this nice policy where we should open upstream bugreports and contribute all patches back, so they should in theory be always somewhere else too :-) > > > so we can say someone get hardware that > > is at least decade old, honestly just obtain distros build around > > such HW (like debian stable). > > Gentoo is about choice. I bet, many Gentoo users have at least some old > hardware device which they want to use. Maybe occasionally, they also > inherit some which they want to use. You really want to scare all > these users away? Yes gentoo is about choice but the choice does not mean to contain everything possible in the tree. We keep the tree maintainable and working for everyone, it is not just some junkyard of whatever did compile few years back for lucky people. Actually suse/fedora and others remove packages way more than us, they just do it with each release so it does not happen here and there but just once every 6 months (or whatever is their release cycle). > > >> Or if he was not yet a gentoo user at the time when the package was > >> removed (or absent/busy for a long period)? > > > > Well he would found out after sync > > Perhaps there was a misunderstanding: > How can someone who starts to use Gentoo in a year find out after sync? > Or another one know a year in advance that he will have the need for some > special software (e.g. to support a device which he inherits in a year)? So when he starts using Gentoo he can look up if the sw he needs is supported and go elsewhere if it is not, or actually contribute and do some stuff about it to make it work for himself. Basically our goal is to create good distribution for us. There is no goal to dominate market or something like that. Take a look on ubuntu, tons of people are using it but it does not help the development team because not much of those contribute back. We rather preffer people that actually can and contribute back. When looking on our stats the user counts seem quite same so we are not losing any user share lately, but on contributors side seems like people are just consuming than contributing back. And contributors are the only ones that are important as they help you in our job. > > > Gentoo is not a distro with bigger resources > > I agree: If none of the developers is interested in a package, > it is completely fine to declare it as unsupported and to require the > user to maintain it himself (or hire somebody) if he wants to use it. > > Masking it is perfectly fine > (maybe another idea would be to introduce some new "state" for such > unmaintained packages so that they are usually ignored). As I said above, cvs tree is not junkyard of something that used to work, so keeping stuff around and masked is actually burden for us, where you as user interested in the package should care. We have to track bugs and react on those even for the masked packages... > > I just ask that Gentoo should not *hinder* the user in installing/ > maintaining a package later by removing the tarballs (and possibly > patches) which once were available. Managing tarballs is upstreams job, if that dies you can still try to get it from rpm/deb packages if such are around. If not then probably nobody ever cared that much, so seek alternative tools for your job. We lack the tool for the patchsets only and that is for infra to solve. But see above what I wrote about the patches, they must be somewhere if maintainer didn't slack and adhere to the policy. > > If these mild (essentially only storage) resources are *really* a severe > issue for Gentoo (or uninstalled masked packages should cause a > considerable slowdown for portage's resolver) then Gentoo has a much > more severe resources problem (or technical problem with portage)... > No distribution does archive tarballs for upstream that was removed. The problem is that it stays around for a bit longer in the release based distros as they have some 1-2 year maintenance cycle for which they keep repos around. But when this point is hit everything disappears. There is no purpose in wasting storage/bandwidth to mirror stuff that is marked obsolete. Btw did any of you guys look on how much packages were removed just for being dead upstream? They usually have to became maintenance nightmare too before they are pruned. I myself didn't check that out but I bet it will be not that much of the removals. Most of them just have some running web page and they just simply don't build and nobody wanted to fix them.
