Richard Brown schrieb:
On 11 August 2014 11:11, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
The fact is, that the old-style init script is the way for people to get their old configuration working during update.
For new installation, the runvdr-extreme-systemd package is preferred.
Now the old script was removed and a symlink rcvdr was added, which breaks the update path.
Now I could have done this from the start, because keeping the update path is painful and a lot of work, just removing working things is easy.
But I actually tried to care for my users. Something that is apparently totally out of scope nowadays.
So changes that add/provide native systemd support are *good* and *welcome* for Devel projects.. square peg, square hole
Yes. Exactly. That's why I kept the init script *as an option, it was even in its own subpackage*, so that users expecting square pegs (old style /etc/sysconfig configuration) would get a working setup.
Now I would not have objected, would the SR have also included a converter from /etc/sysconfig/vdr to /etc/runvdr.conf, but that is not the case AFAICS.
If you want a project in OBS that does not feed into Factory, and isn't co-maintained by the factory-maintainers group, then don't have it as a Devel repo.
So this means I have to file a drop request for VDR from Factory before I go on two weeks vacation next week?
Or alternatively, why don't you reach out to that community member who made the changes to vdr (not the factory-maintainer who accepted it after a week of no activity) and work with them to implement some of the options you propose above?
There is a great opportunity here to work with someone new who is also clearly interested in 'your' vdr package
Instead of complaining that a factory-maintainer accepted an SR which was left idle for 7 days, you have an opportunity to work with someone new who potentially could help you make the vdr package better for all scenarios (systemd, non-systemd, upgrades, fresh installs)
VDR is a rather special beast. Can we please stop here and agree that a) sometimes submit requests are made with the best intentions, look good from the outside but are still suboptimal for the package which only the maintainer can know b) factory-maintainer override is sometimes necessary to keep Factory in shape c) one week inactivity timeout for a leaf package that is not crucial for anything is a bit too tight Ok? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org