On Tue, Feb 24, 2009 at 04:55:27PM +0100, anicka@suse.cz wrote:
As for the second plus, I am not aware that anyone uses this information. AFAIK
Oh YES! I'm certainly using this information all the time.
we have no tool to present it to our users in a neat way. It is even not a part
There *is* a very nice tool, "yum --changelog update", which does exactly that, and which will hopefully be doable with zypper in the future. It is one of the things that makes it very hard for me right now to use zypper. It quickly becomes an essential feature, once you know about it. It's not a well-known feature in the openSUSE world I guess. openSUSE tools haven't got this far, and while what we call "patches" has achieved something remotely similar, it is more meant for end-user who are not interested in details though. (And who hopefully forgive the lousy texts that are presented there.) I have a few systems these days where I evaluate zypper, and I it may sound weird but I actually run "yum --changelog update" in addition to zypper, just to see what happens, because this information is so helpful, while zypper offers me only "meaningless numbers". I use the information to be prepared for upcoming breakage, to appreciate welcome fixes, remove workarounds possibly existing locally, and, very convenient, to judge whether a package has simply been *rebuilt* or *changed* at all. All this is fundamental for me both in my role as developer as in my role as administrator. (Knowing if a package has been rebuilt or changed doesn't require detail in the changelog, though, one line is enough, so it isn't actually relevant to the topic of your post.) [...]
In fact, when you are interested in upstream changes, in almost every case it is more useful to take a look to upstream changelog because it is complete and better structured. When you are interested in specfile changes instead, you cannot just read them, you have to skip tons of useless information from upstream changelog - in fact, even when there is no upstream changelog, it would be better to maintain some as a patch than to pollute RPM changelog with a noise.
Stupid wisdom: what's noise for you, can be information for somebody else, who is actually working with the package. The fact that not everybody looks at the changelog doesn't mean that it's not useful for some people. So there is no need to argue about that. Having said that, I personally don't *require* a detailed changelog. I may appreciate it very much when it's there, should I look for it, but well, that's all. I guess if it's helpful for *yourself* as a packager in some way, make it detailed. It certainly was helpful for myself as a packager, taking the time to go over the changelog, reformatting it, and noticing each change. It let me be well oriented about what's going on upstream and in the package that I'm inflicting on a lot of users. It takes care, but it has a value for me, so I take the time. Thanks, Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org