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.
Visit: https://packageninjas.github.io/packaging/2020/10/13/news-in-packaging.html
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.
Packaging "is not static knowledge"? Fair enough. But it's far too dynamic on openSUSE, for my taste. Not to mention that a few folks need to maintain backward compatibility with old SLE releases in their packages. Such people get little benefit from new features, but still have to deal with the depreciations.
I realize it's too late, the ship has sailed long ago as far as the current changes are concerned. But I wish we'd not repeat this exercise too soon.
Regards Martin
(*) According to firefox' "print preview"
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.
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 vojtech.zeisek@opensuse.org Odesláno: pátek 20. listopadu 2020 17:17 Komu: factory@lists.opensuse.org 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/
Dne pátek 20. listopadu 2020 18:01:52 CET, Kristyna Streitova napsal(a):
Hello Vojtech,
Hi :)
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.
It's good there is such a good and exhaustive description. If there would be also such a good quick how to for beginners, it'd be really beneficial, as the lower entry barrier, the more contributors.
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 :)
Perfect :-)
Best regards, Kristyna Streitova
Yours, V.
Od: Vojtěch Zeisek vojtech.zeisek@opensuse.org Odesláno: pátek 20. listopadu 2020 17:17 Komu: factory@lists.opensuse.org 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.
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/
On Sat, Nov 21, 2020 at 3:22 AM Simon Lees sflees@suse.de wrote:
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/
There's also a general RPM Packaging Guide that I've been referring to folks: https://rpm-packaging-guide.github.io/
There isn't much that's distribution specific in there, though I'm sure contributing some advanced topics that are SUSE specific would be welcome.
On Fri, 2020-11-20 at 16:02 +0000, Martin Wilck wrote:
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.
Visit: https://packageninjas.github.io/packaging/2020/10/13/news-in-packaging.html
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.
Packaging "is not static knowledge"? Fair enough. But it's far too dynamic on openSUSE, for my taste. Not to mention that a few folks need to maintain backward compatibility with old SLE releases in their packages. Such people get little benefit from new features, but still have to deal with the depreciations.
I realize it's too late, the ship has sailed long ago as far as the current changes are concerned. But I wish we'd not repeat this exercise too soon.
Regards Martin
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.
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.
Regards,
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
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
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 :)
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.
I prefer the second one. Else the human race would still live in caves. And learning new stuff and technology is at least for me much more fun than doing always the same.
Thorsten
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?
Hi all,
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 :)
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.
"People have complicated a complicated relationship with change. I'd like to say nerds specially have a really complicated relationship with change. We love it to peaces changed, awesome ... when we're the ones doing it." [1]
[1] https://youtu.be/o_AIw9bGogo?t=1523 The Tragedy of systemd, Benno Rice, 25:23
Kind regards, Petr
Or become innovative, solve problems, introduce new technology? This means we have to continously learn something new and adjust our policies.
I prefer the second one. Else the human race would still live in caves. And learning new stuff and technology is at least for me much more fun than doing always the same.
Thorsten
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
On 11/21/20 2:32 AM, Martin Wilck wrote:
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.
Visit: https://packageninjas.github.io/packaging/2020/10/13/news-in-packaging.html
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.
Packaging "is not static knowledge"? Fair enough. But it's far too dynamic on openSUSE, for my taste. Not to mention that a few folks need to maintain backward compatibility with old SLE releases in their packages. Such people get little benefit from new features, but still have to deal with the depreciations.
I realize it's too late, the ship has sailed long ago as far as the current changes are concerned. But I wish we'd not repeat this exercise too soon.
The vast majority of these changes are new things you can now do because they make your life easier not things that your expected to know / do. We try to do a reasonable job of backporting new macro's back into older versions, the main issue you might hit is if you try to build for SLE rather then SLE Backports repo's on openSUSE's build service as the former doesn't have access to update repos.
-
Jan Engelhardt -
Kristyna Streitova -
Martin Wilck -
Martin Wilck -
Neal Gompa -
Petr Vorel -
Richard Brown -
Simon Lees -
Thorsten Kukuk -
Vojtěch Zeisek