On Fri, 2020-11-20 at 19:02 +0100, Thorsten Kukuk wrote:
I see this as voting-by-feet, at least in part. By changing the rules every other year, we make it harder than needs to be, and less likely that people will enjoy contributing to our project.
That's the old problem: keep everything static, so that people don't need to learn something new? This would mean maintaining openSUSE to dead that nobody is interested in it anymore at some point in time.
Or become innovative, solve problems, introduce new technology? This means we have to continously learn something new and adjust our policies.
Sure, and everyone of us does this every day. It's just not that
learning new rpm macros (and forgetting the previously learned, now
suddenly deprecated ones) is everybody's keenest interest.
Are you seriously claiming that replacing "pkgconfig(systemd-devel)" by
"pkgconfig(libsystemd)" is exciting new technology? The reasoning given
for this is "it can help to shorten the build chain in OBS". So what?
Why can't OBS figure this out by itself (see below)? Why can't OBS
treat pkgconfig(systemd-devel) in exactly the same way it
treats pkgconfig(libsystemd)? Wait, are there perhaps some cases where
the former syntax would actually be needed? If yes, what are theses
cases, and where is the explanation when exactly to use what? If no,
again, why urge everyone to change their specfiles rather than just
change OBS?
Here is what I'd consider exciting new technology: create in a
translation layer that substitutes the new macros for the old ones for
those distros that want it, before passing the spec file to rpm, and do
that in a fully transparent manner, so that package maintainers don't
have to worry about it. That way technology would advance under the
hood, and developers could focus on advancing the technology in those
areas they're truly interested in.
Regards,
Martin
--
Dr. Martin Wilck