Paul Stear posted on Mon, 07 Sep 2009 15:34:02 +0100 as excerpted: > Thanks Duncan, that was the problem. I put an entry in package.use and > all is well libdbi is not now required. As far as I know I do not need > sql for syslog-ng which I have been using for years without any problem. > I wonder if this is a new flag for that program.
It seems to be, yes. A quick epkginfo to see what versions are available says there's a 2.0 and a 2.1 version in-tree, in addition to the 3.x version that's new. A quick emerge -pv =<version> on the 2.x versions did indeed show the flag as disappearing, so it must be new, or at least newly unmasked. But there's a few other changes with the 3.x version as well. I have a bit of a customized syslog config, spitting out various messages to specific files and filtering a few of them, and I had to google for a couple of the new features as it was protesting that the ones I was using were deprecated and not particularly well performing. But the sql thing is either for hyper-control people (and I thought /I/ was bad!) or more practically, for those using a syslog server to manage a few hundred or thousand machines. In that case, yes, I could see how a database backend could be /quite/ helpful indeed! But I don't see any reason for someone running it for just their own machine, or even for 2-3 machines on a home network, to need the extra complexity of the database setup. Maybe at a half-dozen or so machines, if they're all logging to a central server... Anyway, to maybe save you some trouble if you have multiple filters configured, the former match filter is now much broader. To get similar functionality to the previous, simply s/match/message/. Other than that, and the SQL building problems you experienced, it seems to be pretty much the same, tho somewhat more powerful than it was if you need it. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
