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: [email protected] > [mailto:[email protected]] On Behalf Of [email protected] > 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 > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
