Hi Rainer,
> Hi Michael,
>
> as I have blogged, I am not yet sure about how to handle the situation.
> I am also consulting with Autotools experts, any advise is appreciated.
>
> Two packages seem useful, especially when more plugins become available
>
> (I myself think about email and a couple of other databases). Many folks
> also do not like the idea of having to have libmysql present on the
> system just to install rsyslog - with a core package and the plugin,
> those can only install the core (and that will probably the majority
> of cases).
Yes, I totally agree with what you're doing, as making rsyslog modular is
better overall for the product as a whole, as it will allow contributors
easier access to have their own plugins in place without needing to release
rsyslog each time.
> What I have not yet found - and I have very limited expertise in this
> area - is how to do that in the best possible way.
I've asked both Dag and Dries (from rpmforge) on the best way forward as these
guys have years of knowledge behind them for packaging (in the RPM space though).
I'm not sure they'll reply though, as sometimes my questions to them are
ignored and sometimes they are responded to (some questions I ask go into
their "too hard" basket which I think is why they ignore them :P ). I have
been querying, requesting, suggesting, etc things off them for more than 7
years now, so they may be sick of me (joking) :).
I have been asked to become a packager for them before (and for Axel Thimms
who does ATrpms.net - they're all merging into one large repo eventually) but
declined as I have little time as is to contribute to the projects I'm
currently working with.
> Oh, and some more background: ones the plugin interace has matured (I
> expect this in 3 to 6 month), I intend to actually use ommysql with its
> own version number. Versioning will be handled by the interface (that
> part is already present, but no code for it yet as there is only a
> release 1 of it). So, in the medium to long term, ommysql *will* be a
> separate project - maybe one with a different maintainer, as I am no
> mysql guy.
>
> Does this make sense? As I said, comments are much appreciated...
Yes and I do agree with it all. I'm just not personally sure of the best way
forward myself, but I would suspect something along the lines of having one
spec file for rsyslog, and another for rsyslog-mysql would likely be the right
way to go.
If neither Dag nor Dries answer me, I might even try Axel and if he also
doesn't respond (he usually does) then I'll just start on the packaging
myself, doing rsyslog and rsyslog-mysql.
In the long term, it would be better though if rpmforge or atrpms.net would
take on this packaging system. I realise Red Hat will have a "base" one
available in Fedora and then eventually an EL release, but they dont' do
updates, just bugfixing, once they release it for an enterprise product. Which
is where 3rd party repo's make sense.
Regards,
Michael.
> Rainer
>
> > -----Original Message-----
> > From: Michael Biebl [mailto:mbiebl at gmail.com]
> > Sent: Friday, September 28, 2007 10:23 AM
> > To: rsyslog-users; Rainer Gerhards
> > Subject: Re: [rsyslog] rsyslog 1.19.8 released
> >
> > 2007/9/27, Rainer Gerhards <rgerhards at hq.adiscon.com>:
> > > repeat message processing. The MySQL functionality is now taken out
> > of
> > > the core package, but its tarball is still contained in the main
> > tarball
> > > (so it is still a single download for everything). This is part of
> > the
> > > effort to fully support third-party plugins. Rsyslog 1.19.8 is a
> >
> >
> > To be honest, I don't particularly like this change. It increases the
> > work for package maintainers (like me). You now have to maintain two
> > source packages. Having a non-standard tarball inside a tarball
> > doesn't help there. It even worsens things, as stuff like "make dist"
> > or "make distcheck" doesn't work anymore for a cvs checkout.
> > There's also the problem of which version of the plugins will be
> > compatible with the core version (upgrade scenarios, keeping them in
> > sync, etc.)
> > It also adds complexity for the developer (as he has to maintain an
> > additonal set of build files).
> > As you were talking about 3rd party plugins (with the emphasis on 3rd
> > party) I don't understand the benefit of splitting out the mysql
> > plugin as it is you who develops the mysql plugin, not a third party.
> > Do you actually intend to create a separate tarball for each plugin in
> > the future?
> >
> > What was wrong with the --enable-mysql configure switch? I don't see
> > any benefits, only disadvantages. You know, if it ain't broken, why
> > fix it ;-)
> >
> > Cheers,
> > Michael
> >
> >
> > --
> > Why is it that all of the instruments seeking intelligent life in the
> > universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
------- End of Original Message -------