The first bug was filed end of October and is already fixed in cvs. It would be great to have this up to date soon. See bugs #68916 and #69032. The second is an issue already mentioned in 2002. Back then it was the size to keep Changelog remote. See bug #6870. Frankly I can't accept size as a reason. Yes, it's a 130k+ file. But will not rsync take care of this? Better than me having to reload the whole file each single time and having to manage it manually? BTW: it would tell one right on top about world having moved... Reproducible: Always Steps to Reproduce: 1. man 1 emerge, see sections "EBUILDS, TBZ2S, CLASSES AND DEPENDENCIES" and "FILES" 2. less /usr/portage/sys-apps/portage/ChangeLog Actual Results: manpage tells old location, Changelog refers to remote cvs version. Expected Results: manpage should tell actual location, Changelog should be local.
dont file new bugs when you already know old ones exist just comment on the old ones
well, actually there should be a completely different Changelog in the tree as tree Changelog != upstream Changelog (and the Changelog in CVS is our upstream Changelog). Nick, the ebuild is your territory, your opinion?
The CVS changelog is completely irrelevant as it's not the ChangeLog entries that are posted to the tree. I tend to not fill in the portage changelog as it's mostly unhelpful as the comments are 99% "Version Bump" or "Updated Cleanup Code" for the ebuilds themselves. I'll see about using the changelog more, but it will not be the CVS changelog. You have easy access to it, and we don't need multiple versions of it wasting space in circulation. Size does matter as everyone receives a copy at least once.
Three scenarios I encountered already: a) The machine had no access to the internet and I wasn't able to retrieve the changelog from remote. So I wasn't able to read the changelog. One can say "then get to a machine which has access" or "you could have retrieved the changelog beforehand". Or I could have replaced the placeholder within the portage tree for this very machine. No problem as no sync would overwrite my changes. Or I could do other things until I get access to the internet and then retrieve the data and examine the issue that made me try to read the file earlier. b) Within a network I tried to look up the changelog on machine A and had to retrieve it there. The next time, I tried to read the changelog on machine B. As machine A wasn't up that time I had to retrieve the data from remote again. But there's no problem, I could have distributed the file to all my machines beforehand, to have at least the changelog available which fitted the current installation of that package. I just have to keep track of the package itself. And to retrieve a single file and distribute it to all machines is done quickly. c) As reported by others, to retrieve that file doesn't reliably yield the changelog. One has to retry once or more to get the file. But that is no problem, just retry the download. Each of these situations has a solution to have the file at hand. I should better call them weak workarounds. Where to store the changelog? With each sync the portage tree gets rebuilt so putting the file there manually doesn't help. I have to keep it separate. And keep in mind where I actually have it. When to get the changelog from remote? Each time I update the package (which thankfully isn't each single day). So I have to have in mind that if portage gets updated I have to retrieve a copy of the changelog and place it where I decided to keep it. Outside of portage tree, of course... And to assert I really got the file I just have to open it and look it up. But there already is a mechanism to do all that _and_ keep the data at the place all other packages have their changelogs as well. So why don't use it? Yeah, the size. That sounds like a very good reason. But it's not. It would be a good reason if the data in this file were of little value and only a few people looked up that information. Oh, it is only a few? Really? How do you know? From the access data of the changelog? If so, what I question, does everybody who'd like to read the data actually retrieve them when he doesn't have them at hand? Jump the hurdle to read the data? So these data must be of little value. Really? Then why do you keep them for all the other packages? It would save more space to get rid of all of them. So these data actually have value. Jump the hurdle to get valuable information. Is that good education of the user base? Certainly not, it's a very good way to tell them that some information just isn't meant for them to be read. Or everybody does indeed retrieve the file manually so there is no gain not to use the mechanisms sync provides. To the contrary. The only good reason could be the fact that the changelog isn't of the same kind as of all other packages' changelogs. But as long as there is no such changelog it would be a very good interim solution to put this /wrong/ changelog there. Even better as one gets the information to retrieve that /wrong/ changelog manually. But it's resolved invalid... Thanks.
Ok, I did my homework. Sascha Silbe pointed me to the local copy in /usr/share/doc as being not just another annoying reference to the cvs changelog. Therefore I rethought my criticism and came to the following conclusion: - one aspect of my criticism is partially invalid. I do have a snapshot of the changelog and there is no need to get one myself and keep track of this. But then a reference to this local copy is still missing. - the whole rest of my criticism is fully valid. The copy in doc tree doesn't change the issue at hand. One still needs to manually retrieve the whole cvs copy to see the most interesting parts of the changelog.
