Hello Vojtech, The article is definitely meant for people who already have some packaging experience. But we still tried to explain things in a way so even less experienced people can understand it (I hope). We also added lots of links so they can follow them if they want to know more. We registered our Package Ninja blog in planet.opensuse.org so it was published there and you will also find all of our future articles there :) Best regards, Kristyna Streitova ________________________________ Od: Vojtěch Zeisek Odesláno: pátek 20. listopadu 2020 17:17 Komu: factory@lists.opensuse.org Předmět: [opensuse-factory] Re: [opensuse-packaging] "Keep up with openSUSE Packaging" article Dne pátek 20. listopadu 2020 17:02:42 CET, Martin Wilck napsal(a):

On Fri, 2020-11-20 at 15:32 +0000, Kristyna Streitova wrote:

...

I would like to point you to the pretty extensive article about news and important changes in openSUSE Packaging we wrote. It covers recent changes in macros, paths, tags and also new and cool features in RPM or OBS.

It looks very detailed (good), but not for beginners. Was this intentional? :-)

...

Visit: https://packageninjas.github.io/packaging/2020/10/13/ news-in-packaging.html

Could it be also at https://news.opensuse.org/ and/or https:// planet.opensuse.org/ ? It'd help people to find it.

...

I believe that whether you are a pro package maintainer or just a casual packager who wants to catch up, you will definitely find here something you didn’t know.

This feels very wrong to me. Contributors, in particular "casual packagers", shouldn't have to go through a 30-page document(*) just to keep up with changes in packaging. Packaging should be *easy*, *fun*, and *quick*, and should take as little as possible precious developer attention. We've turned it into a science, and a cumbersome and boring one at that. I haven't researched any details, but at a glance it feels as if we're deprecating things that we've introduced just a short while ago.

I was browsing https://en.opensuse.org/Portal:Packaging if I find some quick howto for dummies (BFU), but I wasn't successful. IMHO something like this --- up-to-date and enough fool-proof --- would be super beneficial for everyone, especially for casual packagers. -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/

On 11/21/20 2:47 AM, Vojtěch Zeisek wrote:

Dne pátek 20. listopadu 2020 17:02:42 CET, Martin Wilck napsal(a):

...

On Fri, 2020-11-20 at 15:32 +0000, Kristyna Streitova wrote:

...

I would like to point you to the pretty extensive article about news and important changes in openSUSE Packaging we wrote. It covers recent changes in macros, paths, tags and also new and cool features in RPM or OBS.

It looks very detailed (good), but not for beginners. Was this intentional? :-)

Duncan wrote a great beginner guide so I just point people back to that https://duncan.codes/tutorials/rpm-packaging/ -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Fri, 2020-11-20 at 17:29 +0100, Richard Brown wrote:

I respectfully but strongly disagree.

Packaging is not static knowledge, and the requirements that packaging has to fufil is not static.

This article documents packaging changes which all happened as a result of requirements in Tumbleweed, MicroOS, Leap/Jump, SLE or other SUSE Products.

None of this was 'change for changes sake'.

If if you very narrow mindedly consider only what is clearly on the horizon for SLE, there is no avoiding change at the sort of level you see captured in this document.

On the contrary, I'd expect some to argue that all this change isn't enough and more significant, rapid, and invasive changes to how we package things to be necessary.

Sure thing. Some people say that rpm itself is obsolete 20th-century technology. We've had this discussion many times - outside the narrow world of rpm-based distros, hardly anyone cares about this stuff. 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.

In such an environment, I find articles like this one put together by Vitezslav and Kristyna to be absolutely wonderful and like to encorage them to write more, at this level of detail, as often as they can.

I didn't say the article was bad. Quite to the contrary, it's a nice source of information. I'll make sure I bookmark it for the next time my packages fail some lint check (along these lines - why is document located on github rather than on the openSUSE Wiki, where people would primarily look for it? So far I didn't even find a reference on the Wiki). There's one point where the article falls short IMO, and that's backward compatibility. For each of the new macros, it should at least tell on which distros/service packs it is (or will be) available. I'm generally fine with changing my spec files, but I positively hate having to add conditionals because newer flavors require using macros that old ones don't have. Martin -- Dr. Martin Wilck , Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer

On Friday 2020-11-20 19:02, Thorsten Kukuk wrote:

On Fri, Nov 20, Martin Wilck wrote:

...

Sure thing. Some people say that rpm itself is obsolete 20th-century technology. We've had this discussion many times - outside the narrow world of rpm-based distros, hardly anyone cares about this stuff.

Hey, even Microsoft did choose RPM for their Linux Distribution ;) So RPM cannot be that obsolete :)

It is ultimately just a container for files and then some more data. That is about as exciting as it gets. In principle easily replacable by anything else

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?

That's just a lot of euphemisms for recreating systems (“those who don't understand $old_tech are bound to reimplement it, poorly”). Lack of interest can be a sign of maturity! Think /usr/bin/less. less is not "interesting". less is not anywhere close to the top 10^n searches on Google (pick some n) compared to, say, Rust. less does not have problems that need solving. less does not make problems in the first place. less does not introduce new technology. less is not "innovative". less is just fine. But if it did not exist, people would notice. Or can you name a severe problem or magical innovation in 20+ years of /usr/bin/less's history?

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 , Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer