----- Original Message ----- > On Wed, 17.07.13 00:08, Ding Yi Chen (dchen@xxxxxxxxxx) wrote: > > > > > that monitor /var/log/messages > > > > > > A) If someone is installing a program that expects this file, they can > > > also > > > install rsyslog. > > > > a) From what command they know they need to install rsyslog if they want > > yum -y whatprovides /var/log/messages > > gives no result. > > If I did not follow the fedora-devel, I would not know why the > > scripts failed. > > The release notes addition we suggested in the feature page tells you > what to do. > > The feature page also says we'll add /var/log/README explaining the > situation. > > It would be useful actually if you raised these points only after reading > the thread, because this has been discussed quite a few times already on > this thread. In theory, everyone should read the ChangeLog, RELEASE-NOTES, and manual on every thing he/she uses. In reality, well ... What's the percentage of your friend and family actually finish read all the document they supposed to read? > > b) For user that do upgrade from backup user data/scripts->fresh > > install->restore data/scrips > > How they suppose to know that /var/log/messages is gone without checking > > the Release-Notes? > > Not everyone have time to go through all the changes. > > If you look for the files, you should hopefully notice /var/log/README > and understand. > > > > B) Fedora, RHEL, and most Red Hat derived distributions use > > > /var/log/messages, but not all do -- for example, Rocks (common in HPC) > > > breaks out syslog messages into individual files per facility. Debian and > > > Ubuntu? Totally diferent. (/var/log/syslog) > > > > > > So, these third-party scripts need to be flexible anyway. I don't think > > > this > > > is a very strong point in the conversation. > > > > You falsely assume that: > > a) 3rd party developers support every operating systems under the sun, > > including all version of Windows, DOS and MacOS. > > b) 3rd party developers aware the changes > > c) 3rd party developers can and will diligently update their script > > just for Fedora. > > Well, but it is very simple: if the 3rd party developer notices the file > is gone, he will look for them in /var/log, and hopefully see the > README. If he doesn't he will likely start googling. And is likely to > find something quickly, given that notoriety of this thread. Should I mention point c) again? Haven't you ever heard of package been orphaned or retired? > We will continue to make changes in Fedora. We are the distribution > which is supposed to bring you the new stuff first. This means changes, > this means you need to keep yourself up-to-date a bit. This is just > another iteration of this. > > If you never want any changes, then Fedora is simply not the > distribution for you. Slackware might be. I want sane changes that does not break my system. Not just change to for change's sake. For example, change from Gnome 2 to 3 does look somewhat nicer, but it break whole lots of applet, and WM like xmonad. That will driven away users. > > > > > Don't tell me that you have not seen people writing multiple platform > > scripts like this: > > > > case $OS) > > Windows* ) > > some_windows_scripts > > ...... > > Linux* ) > > grep /var/log/messages > > > This *already* doesn't work. On Debian-based distros you would already > have to grep /var/log/daemon.log. On ArchLinux-based distros you would > already have to grep journalctl. > > I am sorry, but this is not where Unix was unified, ever. Please update your knowledge, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428097 They have /var/log/messages, yes, it might be different with ours. But yes, they have that. > > > For them: What? Fedora 20 does not work while Fedora 19 does? Blame Fedora > > then. > > > > And for fedora specific 3rd party scripts, now they need to add > > additional check logic on their script. Sometime that's just too much > > to ask. > > We ask this constantly on Fedora. Because Fedora is where innovation is > supposed to take place, not where things are stay frozen in carbonite > forever. Innovation should not be the cost of reliability and portability. -- Ding-Yi Chen Software Engineer Internationalization Group DID: +61 7 3514 8239 Email: dchen@xxxxxxxxxx Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: www.redhat.com Red Hat, Inc. Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC Twitter: Red Hat APAC | Red Hat ANZ LinkedIn: Red Hat APAC | JBoss APAC -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
