I use the OS-provided syslog-ng version for normal systems but for specific cases that need a newer version (centralized logging, web servers, etc) I pin something newer using config management (puppet, chef, etc). This is why we mirror the copr repositories. Considering that fixes are not back-ported across all of these revisions I feel that one year (or six revisions) is more than enough. Your LTS version is usually whatever is maintained by your OS distribution as opposed to something from the syslog-ng guys, but that's up to them to decide. On Thu, Sep 5, 2019 at 10:45 AM Laszlo Budai <laszlo.budai@outlook.com> wrote:

Hi!

Don't really see the importance of having separated repositories for each syslog-ng version as you don't provide updates... (I mean without backporting bugfixes to these repos, this is just a version lock).

But version lock does not require separated repositories: users can pin (yum versionlock eg.) a specific version.

The result is the same...

All in all, these repos do not resolve the LTS vs. rolling release issue (which is not really liked some of the community members :) ).

L.

------------------------------ *From:* syslog-ng <syslog-ng-bounces@lists.balabit.hu> on behalf of Peter Czanik (pczanik) <Peter.Czanik@oneidentity.com> *Sent:* Thursday, September 5, 2019, 09:14 *To:* syslog-ng@lists.balabit.hu *Subject:* [syslog-ng] cleaning up the unofficial rpm repositories

Hi,

Ever since I started my unofficial rpm packages for (open)SUSE and Fedora/RHEL/CentOS I created a new repository for each new release and never deleted them. Of course OBS and Copr guys did sometimes clean ups, so Fedora and openSUSE packages for long end of life distributions got deleted. But for the rest there are still syslog-ng 3.5 packages on-line.

Not everyone likes to update syslog-ng every second month, so I keep the current workflow and create a new repo for each new release. This way your syslog-ng.conf or package management is not accidentally broken at a random time with a new update, you have a chance to test a new release thoroughly before upgrading. On the other hand I plan to keep only a year worth of releases instead of everything.

Question:

- Is there anyone, who needs packages older than one year? With the one year limit I'd delete anything older than 3.17 and delete 3.17 as well, once 3.24 is out, and so on.

Bye,

Peter Czanik (CzP) <peter.czanik@oneidentity.com> Balabit (a OneIdentity company) / syslog-ng upstream https://syslog-ng.com/community/ https://twitter.com/PCzanik

______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq

Evan - run a configuration management agent on your hosts, you can "one click" roll out packages, repos, and config. Some common ones are puppet, chef, terraform, ansible. It's a bit of a time investment at first but an incredible time savings in the long run. On Thu, Sep 5, 2019 at 11:06 AM Evan Rempel <erempel@uvic.ca> wrote:

Agreed. Trying to get 100's of systems upgraded currently requires a new repo to be added to each host. Kind of a pain. The repo structure currently in place pushes a bunch of work onto the package consumers, for what I can see is for no benefit. Just a make work project :-(

As a result, our organization sucks up all of the repos and combines them together. Deleting your repo does not remove any packages from my joined repo, so it makes no difference to me.

Evan.

On 9/5/19 7:45 AM, Laszlo Budai wrote:

Hi!

Don't really see the importance of having separated repositories for each syslog-ng version as you don't provide updates... (I mean without backporting bugfixes to these repos, this is just a version lock).

But version lock does not require separated repositories: users can pin (yum versionlock eg.) a specific version.

The result is the same...

All in all, these repos do not resolve the LTS vs. rolling release issue (which is not really liked some of the community members :) ).

L.

------------------------------ *From:* syslog-ng <syslog-ng-bounces@lists.balabit.hu> <syslog-ng-bounces@lists.balabit.hu> on behalf of Peter Czanik (pczanik) <Peter.Czanik@oneidentity.com> <Peter.Czanik@oneidentity.com> *Sent:* Thursday, September 5, 2019, 09:14 *To:* syslog-ng@lists.balabit.hu *Subject:* [syslog-ng] cleaning up the unofficial rpm repositories

Hi,

Ever since I started my unofficial rpm packages for (open)SUSE and Fedora/RHEL/CentOS I created a new repository for each new release and never deleted them. Of course OBS and Copr guys did sometimes clean ups, so Fedora and openSUSE packages for long end of life distributions got deleted. But for the rest there are still syslog-ng 3.5 packages on-line.

Not everyone likes to update syslog-ng every second month, so I keep the current workflow and create a new repo for each new release. This way your syslog-ng.conf or package management is not accidentally broken at a random time with a new update, you have a chance to test a new release thoroughly before upgrading. On the other hand I plan to keep only a year worth of releases instead of everything.

Question:

- Is there anyone, who needs packages older than one year? With the one year limit I'd delete anything older than 3.17 and delete 3.17 as well, once 3.24 is out, and so on.

Bye,

Peter Czanik (CzP) <peter.czanik@oneidentity.com> <peter.czanik@oneidentity.com> Balabit (a OneIdentity company) / syslog-ng upstream https://syslog-ng.com/community/ https://twitter.com/PCzanik

______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq