[rsyslog] Packages in tarball - was: RE: Get rsyslog to always use fqdn of sending devices?

[Rainer Gerhards]

Hi all,

I have (obviously) no strong position in this. I do not object putting
distro-specific files into a "contrib" directory and make them available
with the tarball *as long as it is clear that I do not support them*.

I concur to David that this may be useful and I also concur to Michael
that it may cause some confusion.

To me, the important point is that I can not support distro-specific
things (at least outside of the core code) and that I will not want to
create and release dependencies. So if we put some package files into
the tarball, that means I will update them if I receivea patch or am
asked to pull the, but I will neither verify them nor will I hold
releases. So, in short, they will be unmaintained and often not matching
the rest of the tarball. HOWEVER, I can see that there are cases where
it would be useful to hae those files available.

On the other hand, at least for Debian, I think it is possible to obtain
the package files from Debian directly (but, granted, it may not have
the newest ones, e.g. v4).

I have a pragmatic suggestion: if you have package specific files, you
can send them to me. I will create a subdirectory for them. There will
be a README telling people that this stuff is (from my POV)
unmaintained, probably outdated and to be used with care. If a
maintainer (like Michael) later decides it was a bad idea to put the
files into the tarball, I'll also happily delete them.

Does this sound like a workable compromise?

Rainer 

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com 
> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of david at lang.hm
> Sent: Saturday, February 28, 2009 3:16 AM
> To: rsyslog-users
> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of 
> sending devices?
> 
> On Sat, 28 Feb 2009, Michael Biebl wrote:
> 
> >>>
> >>> If the fedora bits are kept in an entirely separate 
> upstream packaging
> >>> branch, then I don't really care.
> >>> But I wouldn't like to see them (or any debian related 
> files) shipped
> >>> in a release tarball.
> >>
> >> so how am I (a debian user) supposed to create debian 
> compatible packages
> >> for versions that you don't yet deal with?
> >>
> >> why couldn't you push the debian related files upstream 
> and maintain them
> >> there? (submitting patches, or git pull requests for updates)
> >
> > Pretty simple: It's less work for me and Rainer and more flexible.
> > Say I (for Debian) start adding the files upstream, so does 
> Fedora, BSD, etc...
> > Now when Rainer wants to make a new release to not have any stale
> > packaging files, he would have to ping all package 
> maintainer first to
> > update the build files and push those changes. That simply doesn't
> > scale.
> > Packaging and upstream software releases should be decoupled.
> >
> > If you are really interested in the Debian Packaging, you 
> can grab the
> > git repository from [1] and either work from there or at it as a
> > "remote" to the rsyslog git repo and merge the debian specific bits.
> 
> it's not that I'm interested in debian packaging, it's that I need to 
> install the stuff that you haven't decided to ship in debian 
> yet on my 
> debian system in such a way that I keep the package manager 
> happy (and 
> don't have it overwriting what I've compiled with an update 
> of an obsolete 
> version)
> 
> it's not that the upstream version of the files need to be 
> perfect, but 
> they should be good enough to avoid the need for users to 
> have to fight 
> the packaging system and duplicate your efforts.
> 
> I hate to have to pull in some stuff from your tree and 
> combine it with 
> stuff from the upstream tree because I don't know enough to 
> be sure that 
> I'm both pulling everything I need and not pulling something 
> that will 
> cause grief.
> 
> you've made your decision, count this as one voice 
> disagreeing with that 
> decision.
> 
> David Lang
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
>