[opensuse-factory] Haskell Packaging for Tumbleweed live on Twitch
Fellow Haskell & Tumbleweed Hackers, we currently have somewhat limited support for Haskell in Tumbleweed. We package all tools required to set up a proper development environment (ghc, cabal-install) plus some important must-have applications written in Haskell (xmonad, pandoc, ShellCheck), but nothing beyond that. However, Ondrej and I would like significantly extend our support for the language. First of all, we'll add more popular tools such as hledger, git-annex, and their dependencies. To accomplish that, we've set up a weekly hacking session in which we'll work on our development project [1]. These sessions take place every Tuesday from 11:00 to 13:00 CEST and we'll stream them live on Twitch at: https://www.twitch.tv/peti343 We would like to invite everyone with an interest in Haskell to join the stream's live chat on Twitch and to hang out with us. You are particularly welcome to participate with suggestions, questions, or packaging requests. Best regards, Peter [1] https://build.opensuse.org/project/show/devel:languages:haskell -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
we currently have somewhat limited support for Haskell in Tumbleweed. [...]
Slightly off-topic, but it probably affects you: Why is 'devel:/languages:/haskell' no longer available for Leap 15.1? Werner -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 8 Jun 2020 at 12:46, Werner LEMBERG <wl@gnu.org> wrote:
we currently have somewhat limited support for Haskell in Tumbleweed. [...]
Slightly off-topic, but it probably affects you: Why is 'devel:/languages:/haskell' no longer available for Leap 15.1?
because the difference between Tumbleweed and actual Leap is bigger every month we are in a situation where we have working ghc-bootstrap for TW ( with small exception, s390x arch) but not for Leap. + our long time maintainer of GHC retired from project:( Kind regards, Ondrej Sukup -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 08.06.20 um 14:58 schrieb Ondřej Súkup:
On Mon, 8 Jun 2020 at 12:46, Werner LEMBERG <wl@gnu.org> wrote:
we currently have somewhat limited support for Haskell in Tumbleweed. [...]
Slightly off-topic, but it probably affects you: Why is 'devel:/languages:/haskell' no longer available for Leap 15.1?
because the difference between Tumbleweed and actual Leap is bigger every month we are in a situation where we have working ghc-bootstrap for TW ( with small exception, s390x arch) but not for Leap.
So probably a case for "Closing The Tumbleweed Gap" ? This can also be seen in other repositories, e.g. Application:Geo, where you have to install everything but the kitchen sink from there if you are in need of an application from Application:Geo, just because this repo seems TW oriented. Cheers, Manfred
+ our long time maintainer of GHC retired from project:(
Kind regards, Ondrej Sukup
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jun 8, 2020 at 16:44, Manfred Schwarb <manfred99@gmx.ch> wrote:
Am 08.06.20 um 14:58 schrieb Ondřej Súkup:
because the difference between Tumbleweed and actual Leap is bigger every month we are in a situation where we have working ghc-bootstrap for TW ( with small exception, s390x arch) but not for Leap.
So probably a case for "Closing The Tumbleweed Gap" ?
This can also be seen in other repositories, e.g. Application:Geo, where you have to install everything but the kitchen sink from there if you are in need of an application from Application:Geo, just because this repo seems TW oriented.
Well, the entire point of the devel repos is to develop Tumbleweed, how else do you expect them to work? LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 08.06.20 um 16:49 schrieb Stasiek Michalski:
On Mon, Jun 8, 2020 at 16:44, Manfred Schwarb <manfred99@gmx.ch> wrote:
Am 08.06.20 um 14:58 schrieb Ondřej Súkup:
because the difference between Tumbleweed and actual Leap is bigger every month we are in a situation where we have working ghc-bootstrap for TW ( with small exception, s390x arch) but not for Leap.
So probably a case for "Closing The Tumbleweed Gap" ?
This can also be seen in other repositories, e.g. Application:Geo, where you have to install everything but the kitchen sink from there if you are in need of an application from Application:Geo, just because this repo seems TW oriented.
Well, the entire point of the devel repos is to develop Tumbleweed, how else do you expect them to work?
Nothing against devel repos, but from a Leap user perspective, they are quite frustrating, because mostly there is nothing else if you need an application, besides some random home repos. And in the end, if you start compiling several application yourself, by "hand", you start thinking about changing to debian/fedora/whatever, as they often have a standard rpm file for your needed application....
LCP [Stasiek] https://lcp.world
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jun 8, 2020 at 10:57 AM Manfred Schwarb <manfred99@gmx.ch> wrote:
Am 08.06.20 um 16:49 schrieb Stasiek Michalski:
On Mon, Jun 8, 2020 at 16:44, Manfred Schwarb <manfred99@gmx.ch> wrote:
Am 08.06.20 um 14:58 schrieb Ondřej Súkup:
because the difference between Tumbleweed and actual Leap is bigger every month we are in a situation where we have working ghc-bootstrap for TW ( with small exception, s390x arch) but not for Leap.
So probably a case for "Closing The Tumbleweed Gap" ?
This can also be seen in other repositories, e.g. Application:Geo, where you have to install everything but the kitchen sink from there if you are in need of an application from Application:Geo, just because this repo seems TW oriented.
Well, the entire point of the devel repos is to develop Tumbleweed, how else do you expect them to work?
Nothing against devel repos, but from a Leap user perspective, they are quite frustrating, because mostly there is nothing else if you need an application, besides some random home repos. And in the end, if you start compiling several application yourself, by "hand", you start thinking about changing to debian/fedora/whatever, as they often have a standard rpm file for your needed application....
The point isn't to use devel repos with Leap. And in general, I would suggest that devel repos should not have Leap or SLE targets enabled unless there's a specific compelling reason for it. Mixing devel stuff and Leap makes it difficult to maintain a stable system. If you need to do development stuff, consider using Tumbleweed. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2020-06-08 at 11:43 -0400, Neal Gompa wrote:
The point isn't to use devel repos with Leap. And in general, I would suggest that devel repos should not have Leap or SLE targets enabled unless there's a specific compelling reason for it. Mixing devel stuff and Leap makes it difficult to maintain a stable system. If you need to do development stuff, consider using Tumbleweed.
From a developer perspective, trying to preserve compatibility with
That would be true if devel repos were truly only for distro development. But more often than not, they simply provide more recent versions of certain software packages. Thus, in a way, Leap users have more reason to want to include devel repos than TW users. Obviously, that doesn't work well for complex repos which require updates of core libraries. But for others repos, why not? older distros while moving on the bleeding edge can be an interesting exercise. Of course its sometimes not possible, but it's often worthwhile to try. Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jun 8, 2020 at 1:32 PM Martin Wilck <Martin.Wilck@suse.com> wrote:
On Mon, 2020-06-08 at 11:43 -0400, Neal Gompa wrote:
The point isn't to use devel repos with Leap. And in general, I would suggest that devel repos should not have Leap or SLE targets enabled unless there's a specific compelling reason for it. Mixing devel stuff and Leap makes it difficult to maintain a stable system. If you need to do development stuff, consider using Tumbleweed.
That would be true if devel repos were truly only for distro development. But more often than not, they simply provide more recent versions of certain software packages. Thus, in a way, Leap users have more reason to want to include devel repos than TW users. Obviously, that doesn't work well for complex repos which require updates of core libraries. But for others repos, why not?
From a developer perspective, trying to preserve compatibility with older distros while moving on the bleeding edge can be an interesting exercise. Of course its sometimes not possible, but it's often worthwhile to try.
To me, that underscores a deficiency in our approach, then. What makes it difficult for people to use Tumbleweed that they need Leap with a motley of devel project repositories enabled? -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jun 08, 2020 at 01:38:32PM -0400, Neal Gompa wrote:
To me, that underscores a deficiency in our approach, then. What makes it difficult for people to use Tumbleweed that they need Leap with a motley of devel project repositories enabled?
For me, that's the very principle of Tumbleweed: it's a rolling distribution so that big and backwards incompatible changes which can and do break things can come with _any_ update. Not everyone wants that and I certainly don't. I do have one Tumbleweed system but it's one I do not depend on at all and which has been actually down since something like mid March. I wouldn't consider installing Tumbleweed on a system I need for my work. I want latest versions of a small subset of packages and I'm ready to deal with issues with these selected packages; but that doesn't mean I want a full bleeding edge distribution where _anything_ can be upgraded to a new major version at any update. To be honest, for most of the distribution, I would rather appreciate the exact opposite: the original, more conservative, design of Leap. Because except for the packages inherited from SLE, most of Leap currently works more like the pre-Leap openSUSE, i.e. not distinguishing between major and minor versions of the distribution and just picking the latest version from Factory on every Leap release. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2020-06-08 at 20:13 +0200, Michal Kubecek wrote:
On Mon, Jun 08, 2020 at 01:38:32PM -0400, Neal Gompa wrote:
To me, that underscores a deficiency in our approach, then. What makes it difficult for people to use Tumbleweed that they need Leap with a motley of devel project repositories enabled?
For me, that's the very principle of Tumbleweed: it's a rolling distribution so that big and backwards incompatible changes which can and do break things can come with _any_ update. Not everyone wants that and I certainly don't. I do have one Tumbleweed system but it's one I do not depend on at all and which has been actually down since something like mid March. I wouldn't consider installing Tumbleweed on a system I need for my work.
I want latest versions of a small subset of packages and I'm ready to deal with issues with these selected packages; but that doesn't mean I want a full bleeding edge distribution where _anything_ can be upgraded to a new major version at any update.
To be honest, for most of the distribution, I would rather appreciate the exact opposite: the original, more conservative, design of Leap. Because except for the packages inherited from SLE, most of Leap currently works more like the pre-Leap openSUSE, i.e. not distinguishing between major and minor versions of the distribution and just picking the latest version from Factory on every Leap release.
I suppose that something like this holds for many users. You want the bleeding edge in some specific area (could be video editing, web server, the haskell stack, you name it), and you want the rest to be stable and cause no trouble. Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
this discussion is ... it's simple: 1) I want LAST software and I can Live with sometimes broken backwards compactibility - Tumbleweed 2) I want STABLE and supported software, but I must live with older versions of software - Leap but newer use development repository from OBS and even worse is the idea to use some random HOME repo. Kind regards, Ondrej Sukup On Mon, 8 Jun 2020 at 21:41, Martin Wilck <Martin.Wilck@suse.com> wrote:
On Mon, 2020-06-08 at 20:13 +0200, Michal Kubecek wrote:
On Mon, Jun 08, 2020 at 01:38:32PM -0400, Neal Gompa wrote:
To me, that underscores a deficiency in our approach, then. What makes it difficult for people to use Tumbleweed that they need Leap with a motley of devel project repositories enabled?
For me, that's the very principle of Tumbleweed: it's a rolling distribution so that big and backwards incompatible changes which can and do break things can come with _any_ update. Not everyone wants that and I certainly don't. I do have one Tumbleweed system but it's one I do not depend on at all and which has been actually down since something like mid March. I wouldn't consider installing Tumbleweed on a system I need for my work.
I want latest versions of a small subset of packages and I'm ready to deal with issues with these selected packages; but that doesn't mean I want a full bleeding edge distribution where _anything_ can be upgraded to a new major version at any update.
To be honest, for most of the distribution, I would rather appreciate the exact opposite: the original, more conservative, design of Leap. Because except for the packages inherited from SLE, most of Leap currently works more like the pre-Leap openSUSE, i.e. not distinguishing between major and minor versions of the distribution and just picking the latest version from Factory on every Leap release.
I suppose that something like this holds for many users. You want the bleeding edge in some specific area (could be video editing, web server, the haskell stack, you name it), and you want the rest to be stable and cause no trouble.
Martin
-- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2020-06-08 at 22:13 +0200, Ondřej Súkup wrote:
this discussion is ...
it's simple:
1) I want LAST software and I can Live with sometimes broken backwards compactibility - Tumbleweed 2) I want STABLE and supported software, but I must live with older versions of software - Leap
but newer use development repository from OBS and even worse is the idea to use some random HOME repo.
Thanks. That's the theory. And in theory, there is no difference between theory and practice, right? In practice, even though I've tried, I've never lasted long on openSUSE with only the official repos. Incomplete list of use cases: 1) encounter a bug or problem. Check on software.opensuse.org if there are newer versions which might have the issue fixed, if yes, try to install from that repo to double-check 2) need to install latest upstream release to decide whehter to report a bug upstream or on openSUSE. Installing this from a devel or home project is _way_ easier, cleaner and less error-prone than compiling and installing from source. Most importantly, it much easier to roll back 3) branch package to my own home project to create a workaround / quick fix for some issue. Depending on circumstances, I might choose the official repo to branch from, or something else. 4) branch package to my own home project with some compile time options (e.g. debugging) enabled 5) need some package that never made it into the distro, for whatever reason 6) need a certain feature in some newer version of a certain package. (and this applies not only on openSUSE. While I used Debian or Fedora, it wasn't much different). Btw, I disagree with that general advice against home repos. There's a lot of useful stuff in them. Some people do excellent packaging work but don't bother going through the review process. One shouldn't _blindly_ trust people's home repos, of course. People who do that should have some basic idea of what they're doing. Before installing stuff from other people's home repos, I usually double check what changes they made. More often than not, it's just a single patch for some issue they encountered, a base version update from upstream, or a few simple spec file changes. After all, this is Open Source. I strongly prefer this to installing binary packages offered outside OBS from SW vendors, and even that I do sometimes. The biggest issue with home repos is that many of them are outdated and unmaintained. My own are no exception. But that you'll notice pretty quickly if you look at them. Regards, Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer
On Mon, 8 Jun 2020 at 23:05, Martin Wilck <Martin.Wilck@suse.com> wrote:
On Mon, 2020-06-08 at 22:13 +0200, Ondřej Súkup wrote:
this discussion is ...
it's simple:
1) I want LAST software and I can Live with sometimes broken backwards compactibility - Tumbleweed 2) I want STABLE and supported software, but I must live with older versions of software - Leap
but newer use development repository from OBS and even worse is the idea to use some random HOME repo.
Thanks. That's the theory. And in theory, there is no difference between theory and practice, right?
In practice, even though I've tried, I've never lasted long on openSUSE with only the official repos. Incomplete list of use cases:
1) encounter a bug or problem. Check on software.opensuse.org if there are newer versions which might have the issue fixed, if yes, try to install from that repo to double-check
2) need to install latest upstream release to decide whehter to report a bug upstream or on openSUSE. Installing this from a devel or home project is _way_ easier, cleaner and less error-prone than compiling and installing from source. Most importantly, it much easier to roll back -- developer --> Tumbleweed ( and all devel repos have TW enabled) 3) branch package to my own home project to create a workaround / quick fix for some issue. Depending on circumstances, I might choose the official repo to branch from, or something else. +- Ja , own home 4) branch package to my own home project with some compile time options (e.g. debugging) enabled still OWN HOME 5) need some package that never made it into the distro, for whatever reason --> home project then submit to devel, then to Factory -> win for all, new
pretty bad idea package in openSUSE
6) need a certain feature in some newer version of a certain package.
feel free submit SR to devel project and then to openSUSE: Tumbleweed
(and this applies not only on openSUSE. While I used Debian or Fedora, it wasn't much different).
Btw, I disagree with that general advice against home repos. There's a lot of useful stuff in them. Some people do excellent packaging work but don't bother going through the review process. Then ... why ? openSUSE has one of straightforward process to get package into distribution. One shouldn't _blindly_ trust people's home repos, of course. People who do that should have some basic idea of what they're doing. Before installing stuff from other people's home repos, I usually double check what changes they made. More often than not, it's just a single patch for some issue they encountered, a base version update from upstream, or a few simple spec file changes. After all, this is Open Source. I strongly prefer this to installing binary packages offered outside OBS from SW vendors, and even that I do sometimes.
"We never saw bugreports against Home project/ some branch project packages :D"
The biggest issue with home repos is that many of them are outdated and unmaintained. My own are no exception. But that you'll notice pretty quickly if you look at them.
Regards, Martin
-- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 09, 2020 at 06:50:31AM +0200, Ondřej Súkup wrote:
On Mon, 8 Jun 2020 at 23:05, Martin Wilck <Martin.Wilck@suse.com> wrote:
2) need to install latest upstream release to decide whehter to report a bug upstream or on openSUSE. Installing this from a devel or home project is _way_ easier, cleaner and less error-prone than compiling and installing from source. Most importantly, it much easier to roll back -- developer --> Tumbleweed ( and all devel repos have TW enabled)
I am a developer and say "definitely not". [...]
feel free submit SR to devel project and then to openSUSE: Tumbleweed [...] Then ... why ? openSUSE has one of straightforward process to get package into distribution.
I have some experience with this "straightforward process" and I cannot honestly blame people who decided not to go through it and keep packages in their home projects instead. Sure, you can say (and I've heard it many times before) that it's their (ours, actually) fault that we do not understand that the pecularities of the "straightforward process" are for our own good. But that's not how the world works. Fortunately you (as plural) cannot force people to accept the process so you can either make it more friendly and less annoying (which doesn't seem likely) or live with the result. Come on, the ability of OBS to easily create a custom repository which can be trivially added with "zypper ar" and used on one's system is one of the greatest strengths of OBS and advantages of openSUSE. We should promote it as such, not tell people it's something completely wrong. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 9 Jun 2020 09:45:29 +0200 Michal Kubecek <mkubecek@suse.cz> wrote:
On Tue, Jun 09, 2020 at 06:50:31AM +0200, Ondřej Súkup wrote:
On Mon, 8 Jun 2020 at 23:05, Martin Wilck <Martin.Wilck@suse.com> wrote:
2) need to install latest upstream release to decide whehter to report a bug upstream or on openSUSE. Installing this from a devel or home project is _way_ easier, cleaner and less error-prone than compiling and installing from source. Most importantly, it much easier to roll back -- developer --> Tumbleweed ( and all devel repos have TW enabled)
I am a developer and say "definitely not".
[...]
feel free submit SR to devel project and then to openSUSE: Tumbleweed [...] Then ... why ? openSUSE has one of straightforward process to get package into distribution.
I have some experience with this "straightforward process" and I cannot honestly blame people who decided not to go through it and keep packages in their home projects instead.
Sure, you can say (and I've heard it many times before) that it's their (ours, actually) fault that we do not understand that the pecularities of the "straightforward process" are for our own good. But that's not how the world works. Fortunately you (as plural) cannot force people to accept the process so you can either make it more friendly and less annoying (which doesn't seem likely) or live with the result.
Come on, the ability of OBS to easily create a custom repository which can be trivially added with "zypper ar" and used on one's system is one of the greatest strengths of OBS and advantages of openSUSE. We should promote it as such, not tell people it's something completely wrong.
OBS is (one of) the reason why I am still in love with SUSE (SuSE, openSUSE). Started with Linux after buying as a student Windows 98SE, was very unhappy, bougth then SuSE Linux 6.2 (1999) and never tried another distribution. OBS is one of greatest services I ever used. Thx for OBS. Kind regards, Carsten -- If loving linux is wrong, I dont wanna be right. -- Topic for #LinuxGER
On Tue, 2020-06-09 at 06:50 +0200, Ondřej Súkup wrote:
1) encounter a bug or problem. Check on software.opensuse.org if there are newer versions which might have the issue fixed, if yes, try to install from that repo to double-check pretty bad idea
Care to elaborate? What else do you propose?
2) need to install latest upstream release to decide whehter to report a bug upstream or on openSUSE. Installing this from a devel or home project is _way_ easier, cleaner and less error-prone than compiling and installing from source. Most importantly, it much easier to roll back -- developer --> Tumbleweed ( and all devel repos have TW enabled)
You've got a point here, as in most cases Leap is too far away from latest upstream to even consider an upstream bug report. However, the question remains, what should a Leap user do in such a case? A full distro update to TW is usually out of the question, and wouldn't help the use case (even if the bug was gone after the update, the user would be clueless which of the 1000s of updates fixed the issue). Sure, you can report a bug against Leap, but that puts you into a rather weak position. For those packages that come from SLE, you need to hope that some day SLE engineering, QA, and maintenance will take care of it, that eventually the bug will be fixed, and the fix will be released and forwarded to Leap. There's no guarantee for that to happen. Even if it does, it may take considerable time. As a Leap user, you aren't entitled to get temporary fixes, so you can either wait, or find one yourself. For me, finding a fix includes searching update candidates on OBS and trying them (if the changelog suggests that it might be worth it).
3) branch package to my own home project to create a workaround / quick fix for some issue. Depending on circumstances, I might choose the official repo to branch from, or something else. +- Ja , own home
Why would your own home (or mine) be more trustworthy than anybody else's? Do you consider yourself more competent than all others, in all areas? I certainly don't, and thus I believe than anyone's home is "a priori" (i.e. before taking a closer look) as trustworthy as my own. Besides, after lingering around this community for some time, you get a rough idea whose repos can be trusted. Mind you that most offical packages started out in someone's home project some time in the past.
4) branch package to my own home project with some compile time options (e.g. debugging) enabled still OWN HOME 5) need some package that never made it into the distro, for whatever reason --> home project then submit to devel, then to Factory -> win for all, new package in openSUSE 6) need a certain feature in some newer version of a certain package.
feel free submit SR to devel project and then to openSUSE: Tumbleweed
I tend to do that, but I can't blame those who don't. You probably know that some active developers have expressed their dissatisfaction with certain aspects of the review and distro integration process and have announced to discontinue submitting, while still maintaining the packages in inofficial repos. Moreover, submitting to factory is not necessarily a "win for all". Leap users don't necessarily "win", especially not if the development process is so focused on TW that the developers don't even try building for Leap or SLE. IMO that's a strong reason for enabling Leap targets in devel repositories. At least you see immediately when builds fail, and you can try and fix that if you have time.
"We never saw bugreports against Home project/ some branch project packages :D"
I'm not getting your point. Of course there are bugs in these repos. Of course these repos are not maintained by the openSUSE community at large, but by their respective owners. If a novice user opens a bug against such a package, close it and tell the user to report to the repo owner. That takes no more than a minute. Sooner or later the user will find out if that repo is well-maintained. Just to give in example for the original issue: in the "Printing" project, it's common practice to request a test of newly submitted packages on the latest Leap release. That's sometimes annoying for contributors, but it helps making sure that Leap users can install and use the latest printer drivers, which is a good thing. Lack of printer drivers should not be a reason to have to update to TW. "Printing" may be a bit special, but I am sure the same policy would be applicable in other repos, too. Regards Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer
On 6/9/20 10:47 AM, Martin Wilck wrote:
Why would your own home (or mine) be more trustworthy than anybody else's?
Because you control the .spec files with your own credentials? Every repo maintainer is effectively root on all systems using a particular repo. Even if you initially checked the script parts in .spec files before installing a package the next update could be different. Even if the other home repository owner is not evil, which I generally assume to be almost always true, you cannot be sure that they really protect their OBS password. It's your own trust decision though. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Jun 09 2020, Ondřej Súkup wrote:
-- developer --> Tumbleweed ( and all devel repos have TW enabled)
That's cmpletely backwards. As a developer you need a *stable* system. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jun 15, 2020 at 4:49 AM Andreas Schwab <schwab@suse.de> wrote:
On Jun 09 2020, Ondřej Súkup wrote:
-- developer --> Tumbleweed ( and all devel repos have TW enabled)
That's cmpletely backwards. As a developer you need a *stable* system.
That doesn't mean you need a *stale* system (i.e. Leap). -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jun 15, 2020 at 07:11:45AM -0400, Neal Gompa wrote:
On Mon, Jun 15, 2020 at 4:49 AM Andreas Schwab <schwab@suse.de> wrote:
On Jun 09 2020, Ondřej Súkup wrote:
-- developer --> Tumbleweed ( and all devel repos have TW enabled)
That's cmpletely backwards. As a developer you need a *stable* system.
That doesn't mean you need a *stale* system (i.e. Leap).
There is nothing between Leap and Tumbleweed, and Tumbleweed is not stable. I do use Tumbleweed but I do it on a device that has very little state on it so I can just put it down when it breaks and use another one without major interruption. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2020-06-15 at 07:11 -0400, Neal Gompa wrote:
On Mon, Jun 15, 2020 at 4:49 AM Andreas Schwab <schwab@suse.de> wrote:
On Jun 09 2020, Ondřej Súkup wrote:
-- developer --> Tumbleweed ( and all devel repos have TW enabled)
That's cmpletely backwards. As a developer you need a *stable* system.
That doesn't mean you need a *stale* system (i.e. Leap).
Come on guys, this discussion is pointless. We have Leap *and* TW precisely to give people a choice. The starting point of the discussion was the idea to provide Leap users access to up-to-date software in those areas where they need it, while keeping the rest of the system stable. That's a very reasonable thing to want to have. The question is how to get there. Up-to-date software on older distros can e.g. be obtained by using flatpak, but AFAICS flatpak is no 1st class citizen on openSUSE. Also, it works best for "leaf" packages, less so for other things. As for regular packaging, I hear people say that devel repos don't work for this purpose, because they're all targeted for factory. I wonder whether that has to be that way. In some areas (Rust?) it seems to be commonplace to have to update the entire stack just to be able to install a single leaf package. Even that might be possible on Leap, if such stacks were sufficiently separate from the main OS stack. In other areas, maintaining a Leap version means probably just a number of conditionals in the spec file. It's about whether or not developers care, and invest time into fixing Leap issues. In general, I believe we should educate ourselves not to mechanically respond "install Tumbleweed" when users ask for features. Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On Mon, Jun 15, 2020 at 9:31 AM Martin Wilck <Martin.Wilck@suse.com> wrote:
On Mon, 2020-06-15 at 07:11 -0400, Neal Gompa wrote:
On Mon, Jun 15, 2020 at 4:49 AM Andreas Schwab <schwab@suse.de> wrote:
On Jun 09 2020, Ondřej Súkup wrote:
-- developer --> Tumbleweed ( and all devel repos have TW enabled)
That's cmpletely backwards. As a developer you need a *stable* system.
That doesn't mean you need a *stale* system (i.e. Leap).
Come on guys, this discussion is pointless. We have Leap *and* TW precisely to give people a choice.
The starting point of the discussion was the idea to provide Leap users access to up-to-date software in those areas where they need it, while keeping the rest of the system stable. That's a very reasonable thing to want to have.
The question is how to get there. Up-to-date software on older distros can e.g. be obtained by using flatpak, but AFAICS flatpak is no 1st class citizen on openSUSE. Also, it works best for "leaf" packages, less so for other things.
As for regular packaging, I hear people say that devel repos don't work for this purpose, because they're all targeted for factory. I wonder whether that has to be that way. In some areas (Rust?) it seems to be commonplace to have to update the entire stack just to be able to install a single leaf package. Even that might be possible on Leap, if such stacks were sufficiently separate from the main OS stack. In other areas, maintaining a Leap version means probably just a number of conditionals in the spec file. It's about whether or not developers care, and invest time into fixing Leap issues.
In general, I believe we should educate ourselves not to mechanically respond "install Tumbleweed" when users ask for features.
openSUSE's update process is *far* too painful to keep things fresh. I personally avoid it unless I have to do it, and only submit things to Tumbleweed. If there were no SUSE maintainers in devel:languages:rust, I would have killed *all* stale releases in devel:languages:rust. The whole point of Leap is that it reflects "enterprise stability" (aka stale software that is carefully managed by SUSE). If you want a distribution with newer stuff, then we'd have to revisit the gap we have between Leap and Tumbleweed. If you want fresher stuff landing in Leap, then we need a less painful maintenance update process, and we need reviews to scale up with more packages being submitted that way. It's already bad enough that openSUSE:Factory doesn't have enough people to review all the packages that get submitted into Factory now. You can't have your cake and eat it too. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2020-06-15 15:31, Martin Wilck wrote:
The starting point of the discussion was the idea to provide Leap users access to up-to-date software in those areas where they need it, while keeping the rest of the system stable. That's a very reasonable thing to want to have.
The question is how to get there. [...] I hear people say that devel repos don't work for this purpose, because they're all targeted for factory. I wonder whether that has to be that way.
I would like to think of /games and /devel/gcc running just fine with the devel repo model. But perhaps these are given higher priorities by the userbase and/or maintainers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon 15 Jun 2020 06:24:23 PM CDT, Jan Engelhardt wrote:
On Monday 2020-06-15 15:31, Martin Wilck wrote:
The starting point of the discussion was the idea to provide Leap users access to up-to-date software in those areas where they need it, while keeping the rest of the system stable. That's a very reasonable thing to want to have.
The question is how to get there. [...] I hear people say that devel repos don't work for this purpose, because they're all targeted for factory. I wonder whether that has to be that way.
I would like to think of /games and /devel/gcc running just fine with the devel repo model. But perhaps these are given higher priorities by the userbase and/or maintainers. Hi Like an openSUSE Package Hub, just like it's done for SLE....
-- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) Tumbleweed 20200612 | GNOME Shell 3.36.3 | 5.7.1-1-default Intel DQ77MK MB | Xeon E3-1245 V2 X8 @ 3.40 GHz | Intel/Nvidia up 19:04, 2 users, load average: 0.39, 0.75, 1.52 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 6/16/20 2:05 AM, Malcolm wrote:
On Mon 15 Jun 2020 06:24:23 PM CDT, Jan Engelhardt wrote:
On Monday 2020-06-15 15:31, Martin Wilck wrote:
The starting point of the discussion was the idea to provide Leap users access to up-to-date software in those areas where they need it, while keeping the rest of the system stable. That's a very reasonable thing to want to have.
The question is how to get there. [...] I hear people say that devel repos don't work for this purpose, because they're all targeted for factory. I wonder whether that has to be that way.
I would like to think of /games and /devel/gcc running just fine with the devel repo model. But perhaps these are given higher priorities by the userbase and/or maintainers. Hi Like an openSUSE Package Hub, just like it's done for SLE....
My understanding is Package Hub is generally using the Leap packages so it won't provide much help in this case. -- 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 Tue 16 Jun 2020 09:39:11 AM CDT, Simon Lees wrote:
On 6/16/20 2:05 AM, Malcolm wrote:
On Mon 15 Jun 2020 06:24:23 PM CDT, Jan Engelhardt wrote:
On Monday 2020-06-15 15:31, Martin Wilck wrote:
The starting point of the discussion was the idea to provide Leap users access to up-to-date software in those areas where they need it, while keeping the rest of the system stable. That's a very reasonable thing to want to have.
The question is how to get there. [...] I hear people say that devel repos don't work for this purpose, because they're all targeted for factory. I wonder whether that has to be that way.
I would like to think of /games and /devel/gcc running just fine with the devel repo model. But perhaps these are given higher priorities by the userbase and/or maintainers. Hi Like an openSUSE Package Hub, just like it's done for SLE....
My understanding is Package Hub is generally using the Leap packages so it won't provide much help in this case.
Hi Packages must exist in Factory/Tumbleweed to go back into Backports. Sure version X.Y might exist in Leap, but Y.Z in Tumbleweed which is what would be subbed to this 'Community Backports' repository... It really is just an aggregation of all those later version leaf packages that are present in Tumbleweed, but not Leap. -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) Tumbleweed 20200614 | GNOME Shell 3.36.3 | 5.7.1-1-default Intel DQ77MK MB | Xeon E3-1245 V2 X8 @ 3.40 GHz | Intel/Nvidia up 1 day 3:04, 2 users, load average: 0.33, 0.77, 1.55 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
16.06.2020 03:58, Malcolm пишет:
My understanding is Package Hub is generally using the Leap packages so it won't provide much help in this case.
Hi Packages must exist in Factory/Tumbleweed to go back into Backports.
Sure version X.Y might exist in Leap, but Y.Z in Tumbleweed which is what would be subbed to this 'Community Backports' repository...
It really is just an aggregation of all those later version leaf packages that are present in Tumbleweed, but not Leap.
If package can be built in Leap environment, it would have been built in Leap repository in development project. The problem are packages that stopped building. No amount of reshuffling download location is going to replace someone actively maintaining new versions in old environment. The problem is not "where to offer download", but usual "who is going to maintain them". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-06-16 at 08:32 +0300, Andrei Borzenkov wrote:
16.06.2020 03:58, Malcolm пишет:
My understanding is Package Hub is generally using the Leap packages so it won't provide much help in this case.
Hi Packages must exist in Factory/Tumbleweed to go back into Backports.
Sure version X.Y might exist in Leap, but Y.Z in Tumbleweed which is what would be subbed to this 'Community Backports' repository...
It really is just an aggregation of all those later version leaf packages that are present in Tumbleweed, but not Leap.
If package can be built in Leap environment, it would have been built in Leap repository in development project. The problem are packages that stopped building. No amount of reshuffling download location is going to replace someone actively maintaining new versions in old environment.
The problem is not "where to offer download", but usual "who is going to maintain them".
Sure, maintainance for older OS versions requires precious additional maintainer resources. We can't demand this from people who maintain openSUSE packages in their spare time. All I'm saying is that from a maintainer perspective, trying to fix the build for older distributions is not useless. It broadens the possible range of users for the package, and (at least for an old-fashioned person like me) it's a sign of code maturity if it doesn't just work in the latest environments. So this would also be a call to action for Leap users - rather than complaining that your desired package isn't available for Leap, branch the factory or devel repo package, fix it, and submit it back. One problem is IMHO that we constantly try to "modernize" spec files for Factory. More often than not, this means using rpmbuild features that are unavailable in older distributions. Thus, in a way, we create incompatibility ourselves, where it doesn't need to exist. Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer
On Tue, Jun 16, 2020 at 3:53 AM Martin Wilck <Martin.Wilck@suse.com> wrote:
One problem is IMHO that we constantly try to "modernize" spec files for Factory. More often than not, this means using rpmbuild features that are unavailable in older distributions. Thus, in a way, we create incompatibility ourselves, where it doesn't need to exist.
But this is a catch-22, and an especially bad one: if we wait for SLE releases to fall out of support, we're literally waiting decades to adopt new features. And unlike Fedora, openSUSE does not provide a mechanism in which newer macros can be backported to Leap releases to support the community, and it is extremely painful to get rpm features backported or turned on in SLE/Leap to support the community. It's not a walk in the park in the Fedora community for EPEL (building for RHEL), but it's *way* easier. The Fedora "epel-rpm-macros" package[1] can be updated with backported functionality and macros, and that package is always in buildroots, making it transparent to packagers. And if rpm functionality needs to be backported or enabled for the Fedora community, the process to get them turned on isn't onerous. It's mostly playing the waiting game for the next RHEL point release to get them to show up, but that's *at most* six months now. For example, getting zstd payload support turned on RHEL was nowhere near as painful as it was to get it turned on in SLE. And the endless catch-22 conditions that I have been peppered with since it was first brought up after Fedora switched to zstd payloads in Fedora 30 drives me bonkers. It's literally required more cleverness than I'd like to admit to get it turned on in SLE 15 SP2, and I'm *still* waiting despite the fact it's been switched on there because of some unwritten rule that Tumbleweed has to be backwards compatible with Leap 15.0[2]. In Fedora, packagers are free to adopt newer rpm features that are not backwards compatible with RHEL because the Dist-Git system lets you branch packages for specific target releases (and is the default behavior). You can have separate maintainers for Fedora and EPEL branches, and they can diverge to support those distributions. While many packagers maintain unified spec files across all branches (I do for a lot of them), nobody is required to. As an example, I do maintain separate ones with capnproto for Fedora[3] and EPEL 7[4] (and I have done so in Fedora releases in the past, too), but I maintain a unified one for Pagure[5]. I diverge when I feel it's necessary, and no sooner. And many packages have different maintainers for Fedora and EPEL, with different spec files. This is a completely crap situation in openSUSE, because it means that it's extremely hard to improve the quality of life for packagers. This tug of war where forward progress loses to SLE often means that openSUSE itself can't adopt new RPM features or capabilities to simplify packaging. Nobody wants to consider using it in openSUSE because we can't adopt features in openSUSE Tumbleweed that break SUSE Linux Enterprise. It's why we didn't drop the (useless) BuildRoot tag definition until SLE 11 fell out of support. It's why packagers *still* don't correctly mark license files in package file lists (SLE 12 didn't support it properly until SP3). The community has little influence over what goes on in SLE at that level, and the only way stuff moves forward is if SLE is "trapped" into enabling functionality or backporting stuff. This is horrible and we shouldn't have this problem to begin with! I *really* hope the "closing the leap gap" thing means that this gets better, but I'm not sure it will... [1]: https://src.fedoraproject.org/rpms/epel-rpm-macros [2]: https://github.com/openSUSE/rpm-config-SUSE/pull/26#issuecomment-636795495 [3]: https://src.fedoraproject.org/rpms/capnproto/blob/f32/f/capnproto.spec [4]: https://src.fedoraproject.org/rpms/capnproto/blob/epel7/f/capnproto.spec [5]: https://src.fedoraproject.org/rpms/pagure/blob/master/f/pagure.spec -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 16, 2020 at 08:08:21AM -0400, Neal Gompa wrote:
On Tue, Jun 16, 2020 at 3:53 AM Martin Wilck <Martin.Wilck@suse.com> wrote:
One problem is IMHO that we constantly try to "modernize" spec files for Factory. More often than not, this means using rpmbuild features that are unavailable in older distributions. Thus, in a way, we create incompatibility ourselves, where it doesn't need to exist.
But this is a catch-22, and an especially bad one: if we wait for SLE releases to fall out of support, we're literally waiting decades to adopt new features. And unlike Fedora, openSUSE does not provide a mechanism in which newer macros can be backported to Leap releases to support the community, and it is extremely painful to get rpm features backported or turned on in SLE/Leap to support the community. It has been done with some macros
It's not a walk in the park in the Fedora community for EPEL (building for RHEL), but it's *way* easier. The Fedora "epel-rpm-macros" package[1] can be updated with backported functionality and macros, and that package is always in buildroots, making it transparent to That part is missing. The default configuration you get if you include a release in an OBS project is GA without any updates backported later.
Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-06-16 at 14:15 +0200, Michal Suchánek wrote:
On Tue, Jun 16, 2020 at 08:08:21AM -0400, Neal Gompa wrote:
On Tue, Jun 16, 2020 at 3:53 AM Martin Wilck <Martin.Wilck@suse.com
wrote: One problem is IMHO that we constantly try to "modernize" spec files for Factory. More often than not, this means using rpmbuild features that are unavailable in older distributions. Thus, in a way, we create incompatibility ourselves, where it doesn't need to exist.
But this is a catch-22, and an especially bad one: if we wait for SLE releases to fall out of support, we're literally waiting decades to adopt new features. And unlike Fedora, openSUSE does not provide a mechanism in which newer macros can be backported to Leap releases to support the community, and it is extremely painful to get rpm features backported or turned on in SLE/Leap to support the community. It has been done with some macros It's not a walk in the park in the Fedora community for EPEL (building for RHEL), but it's *way* easier. The Fedora "epel-rpm-macros" package[1] can be updated with backported functionality and macros, and that package is always in buildroots, making it transparent to That part is missing. The default configuration you get if you include a release in an OBS project is GA without any updates backported later.
IIUC, the rationale for this is that the package can be installed on end user systems later without depending on other updates (i.e. the update package shouldn't depend on any updated libraries). Which is reasonable for an enterprise distro. But that shouldn't preclude using more modern macros / rpmbuild features in the build system. So something like "epel-rpm-macros" should be possible for SUSE, too. Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-06-16 at 08:08 -0400, Neal Gompa wrote:
On Tue, Jun 16, 2020 at 3:53 AM Martin Wilck <Martin.Wilck@suse.com> wrote:
One problem is IMHO that we constantly try to "modernize" spec files for Factory. More often than not, this means using rpmbuild features that are unavailable in older distributions. Thus, in a way, we create incompatibility ourselves, where it doesn't need to exist.
But this is a catch-22, and an especially bad one: if we wait for SLE releases to fall out of support, we're literally waiting decades to adopt new features. And unlike Fedora, openSUSE does not provide a mechanism in which newer macros can be backported to Leap releases to support the community, and it is extremely painful to get rpm features backported or turned on in SLE/Leap to support the community.
You're right, it's a catch-22. But so far we've been discussing "latest Leap" only in this thread, not everything that SUSE is supporting for enterprise customers. In general, it's worth discussing for every new rpm feature whether it's adoption on TW/Leap/SLE really makes packagers' lives easier. I understand that your PoV is different from the average SUSE person's PoV, as you do a lot of cross-distro work. I'm certainly more conservative than you are. I wouldn't consider starting to use a build feature only because it's available in Fedora.
It's not a walk in the park in the Fedora community for EPEL (building for RHEL), but it's *way* easier. The Fedora "epel-rpm-macros" package[1] can be updated with backported functionality and macros, and that package is always in buildroots, making it transparent to packagers. And if rpm functionality needs to be backported or enabled for the Fedora community, the process to get them turned on isn't onerous. It's mostly playing the waiting game for the next RHEL point release to get them to show up, but that's *at most* six months now.
For example, getting zstd payload support turned on RHEL was nowhere near as painful as it was to get it turned on in SLE. And the endless catch-22 conditions that I have been peppered with since it was first brought up after Fedora switched to zstd payloads in Fedora 30 drives me bonkers. It's literally required more cleverness than I'd like to admit to get it turned on in SLE 15 SP2, and I'm *still* waiting despite the fact it's been switched on there because of some unwritten rule that Tumbleweed has to be backwards compatible with Leap 15.0[2].
Playing devil's advocate: what's the actual benefit of zstd, other than being "modern"? It uncompresses faster, ok. But when we install or update packages, what percentage of the time is actually spent in decompression, in contrast to downloading, possibly applying deltas, and installing (oh, and rebuilding the intird)? My personal gut feeling is that the net effect of the compression algorithm on the average user's experience is almost negligible, even if the numbers for the algorithm's performance alone look impressive. I don't recall how many times the compression algorithm has been changed since I've been using rpm-based distros. Every time it happened, it's been causing hassle for me, because you suddenly can't unpack packages from newer distros on older ones any more, and I always needed to work on older distros, too. I'm no fan of this sort of change in general.
In Fedora, packagers are free to adopt newer rpm features that are not backwards compatible with RHEL because the Dist-Git system lets you branch packages for specific target releases (and is the default behavior). You can have separate maintainers for Fedora and EPEL branches, and they can diverge to support those distributions. While many packagers maintain unified spec files across all branches (I do for a lot of them), nobody is required to. As an example, I do maintain separate ones with capnproto for Fedora[3] and EPEL 7[4] (and I have done so in Fedora releases in the past, too), but I maintain a unified one for Pagure[5]. I diverge when I feel it's necessary, and no sooner. And many packages have different maintainers for Fedora and EPEL, with different spec files.
We don't have dist-git, but other than that, I don't see what of the above would be impossible on openSUSE. I'm all for trying to provide something like epel-rpm-macros, if that's possible.
This is a completely crap situation in openSUSE, because it means that it's extremely hard to improve the quality of life for packagers. This tug of war where forward progress loses to SLE often means that openSUSE itself can't adopt new RPM features or capabilities to simplify packaging. Nobody wants to consider using it in openSUSE because we can't adopt features in openSUSE Tumbleweed that break SUSE Linux Enterprise. It's why we didn't drop the (useless) BuildRoot tag definition until SLE 11 fell out of support. It's why packagers *still* don't correctly mark license files in package file lists (SLE 12 didn't support it properly until SP3). The community has little influence over what goes on in SLE at that level, and the only way stuff moves forward is if SLE is "trapped" into enabling functionality or backporting stuff. This is horrible and we shouldn't have this problem to begin with!
I *really* hope the "closing the leap gap" thing means that this gets better, but I'm not sure it will...
It's certainly not on top of the agenda (yet). But SUSE has an interest in the backports project, which would in turn benefit from having more packages available for Leap. I do think that SUSE would be interested in improving this situation. Regards, Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 16, 2020 at 10:23 AM Martin Wilck <Martin.Wilck@suse.com> wrote:
On Tue, 2020-06-16 at 08:08 -0400, Neal Gompa wrote:
On Tue, Jun 16, 2020 at 3:53 AM Martin Wilck <Martin.Wilck@suse.com> wrote:
One problem is IMHO that we constantly try to "modernize" spec files for Factory. More often than not, this means using rpmbuild features that are unavailable in older distributions. Thus, in a way, we create incompatibility ourselves, where it doesn't need to exist.
But this is a catch-22, and an especially bad one: if we wait for SLE releases to fall out of support, we're literally waiting decades to adopt new features. And unlike Fedora, openSUSE does not provide a mechanism in which newer macros can be backported to Leap releases to support the community, and it is extremely painful to get rpm features backported or turned on in SLE/Leap to support the community.
You're right, it's a catch-22. But so far we've been discussing "latest Leap" only in this thread, not everything that SUSE is supporting for enterprise customers.
In general, it's worth discussing for every new rpm feature whether it's adoption on TW/Leap/SLE really makes packagers' lives easier. I understand that your PoV is different from the average SUSE person's PoV, as you do a lot of cross-distro work. I'm certainly more conservative than you are. I wouldn't consider starting to use a build feature only because it's available in Fedora.
I'm often driving these improvements in RPM upstream and pushing them to all distros at the same time. Fedora gets it first because this problem isn't as big there. Everything chokes and gets blocked *in Tumbleweed* because of SLE. That's fundamentally broken.
It's not a walk in the park in the Fedora community for EPEL (building for RHEL), but it's *way* easier. The Fedora "epel-rpm-macros" package[1] can be updated with backported functionality and macros, and that package is always in buildroots, making it transparent to packagers. And if rpm functionality needs to be backported or enabled for the Fedora community, the process to get them turned on isn't onerous. It's mostly playing the waiting game for the next RHEL point release to get them to show up, but that's *at most* six months now.
For example, getting zstd payload support turned on RHEL was nowhere near as painful as it was to get it turned on in SLE. And the endless catch-22 conditions that I have been peppered with since it was first brought up after Fedora switched to zstd payloads in Fedora 30 drives me bonkers. It's literally required more cleverness than I'd like to admit to get it turned on in SLE 15 SP2, and I'm *still* waiting despite the fact it's been switched on there because of some unwritten rule that Tumbleweed has to be backwards compatible with Leap 15.0[2].
Playing devil's advocate: what's the actual benefit of zstd, other than being "modern"? It uncompresses faster, ok. But when we install or update packages, what percentage of the time is actually spent in decompression, in contrast to downloading, possibly applying deltas, and installing (oh, and rebuilding the intird)? My personal gut feeling is that the net effect of the compression algorithm on the average user's experience is almost negligible, even if the numbers for the algorithm's performance alone look impressive.
I don't recall how many times the compression algorithm has been changed since I've been using rpm-based distros. Every time it happened, it's been causing hassle for me, because you suddenly can't unpack packages from newer distros on older ones any more, and I always needed to work on older distros, too. I'm no fan of this sort of change in general.
It's a big deal for Tumbleweed, where people do huge update batches multiple times a week. You're right, there are other issues to tackle: excessive scriptlets and useless initramfs rebuilds are other big chokepoints, but improvements there are *also* stalled on this problem. We literally cannot fix anything here because of SLE.
In Fedora, packagers are free to adopt newer rpm features that are not backwards compatible with RHEL because the Dist-Git system lets you branch packages for specific target releases (and is the default behavior). You can have separate maintainers for Fedora and EPEL branches, and they can diverge to support those distributions. While many packagers maintain unified spec files across all branches (I do for a lot of them), nobody is required to. As an example, I do maintain separate ones with capnproto for Fedora[3] and EPEL 7[4] (and I have done so in Fedora releases in the past, too), but I maintain a unified one for Pagure[5]. I diverge when I feel it's necessary, and no sooner. And many packages have different maintainers for Fedora and EPEL, with different spec files.
We don't have dist-git, but other than that, I don't see what of the above would be impossible on openSUSE. I'm all for trying to provide something like epel-rpm-macros, if that's possible.
There are ways to do it. Heck, I do it for one of my private OBS instances by simply importing epel-rpm-macros and adding it as a buildroot support package from another project that updates, so only that thing updates and everything else can stay the same. I've used epel-rpm-macros for SLE/Leap targets too. :)
This is a completely crap situation in openSUSE, because it means that it's extremely hard to improve the quality of life for packagers. This tug of war where forward progress loses to SLE often means that openSUSE itself can't adopt new RPM features or capabilities to simplify packaging. Nobody wants to consider using it in openSUSE because we can't adopt features in openSUSE Tumbleweed that break SUSE Linux Enterprise. It's why we didn't drop the (useless) BuildRoot tag definition until SLE 11 fell out of support. It's why packagers *still* don't correctly mark license files in package file lists (SLE 12 didn't support it properly until SP3). The community has little influence over what goes on in SLE at that level, and the only way stuff moves forward is if SLE is "trapped" into enabling functionality or backporting stuff. This is horrible and we shouldn't have this problem to begin with!
I *really* hope the "closing the leap gap" thing means that this gets better, but I'm not sure it will...
It's certainly not on top of the agenda (yet). But SUSE has an interest in the backports project, which would in turn benefit from having more packages available for Leap. I do think that SUSE would be interested in improving this situation.
Improving the packager experience is key to growing the usable package collection no matter what the target is. Right now, I can confidently say that it hasn't advanced at all since I started actively contributing to openSUSE in 2015. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 6/15/20 11:01 PM, Martin Wilck wrote:
On Mon, 2020-06-15 at 07:11 -0400, Neal Gompa wrote:
On Mon, Jun 15, 2020 at 4:49 AM Andreas Schwab <schwab@suse.de> wrote:
On Jun 09 2020, Ondřej Súkup wrote:
-- developer --> Tumbleweed ( and all devel repos have TW enabled)
That's cmpletely backwards. As a developer you need a *stable* system.
That doesn't mean you need a *stale* system (i.e. Leap).
Come on guys, this discussion is pointless. We have Leap *and* TW precisely to give people a choice.
The starting point of the discussion was the idea to provide Leap users access to up-to-date software in those areas where they need it, while keeping the rest of the system stable. That's a very reasonable thing to want to have.
The question is how to get there. Up-to-date software on older distros can e.g. be obtained by using flatpak, but AFAICS flatpak is no 1st class citizen on openSUSE. Also, it works best for "leaf" packages, less so for other things.
As for regular packaging, I hear people say that devel repos don't work for this purpose, because they're all targeted for factory. I wonder whether that has to be that way. In some areas (Rust?) it seems to be commonplace to have to update the entire stack just to be able to install a single leaf package. Even that might be possible on Leap, if such stacks were sufficiently separate from the main OS stack. In other areas, maintaining a Leap version means probably just a number of conditionals in the spec file. It's about whether or not developers care, and invest time into fixing Leap issues.
In general, I believe we should educate ourselves not to mechanically respond "install Tumbleweed" when users ask for features.
It is possible, especially for leaf packages it just requires more packaging effort and packager's don't always want to do that. One example is in Leap 15.1/15.2 there is a fish and fish3 package, the fish3 package was added post release using the maintenance update process, the fish3 package is in the devel project but not tumbleweed as the fish package in tumbleweed is fish3. The biggest issue is the bigger repo's that have a combination of system libraries and apps where some users want the apps but not the libraries. My personal solution is to branch the few applications that I need to be newer into one home repo but that's not user friendly. Similarly you could take for example all the "Games" people care about that have new version and branch them into a Games:15.1 repo that only has things that wouldn't interfere with other libs the user might have on there system as long as they still build. However for packages to be considered "openSUSE quality" they need to be reviewed etc, and when new packages are being developed for tumbleweed etc they would also get pulled in so this solution isn't something we as a project could recommend as a stable reviewed solution. You could however look at whats being done for devel:lang:python:backports, where packages only sync across to the repo once they are accepted into factory. So there are a couple of potential solutions it is just a matter of whether anyone wants to put in the effort to implement them. -- 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
Hi, sorry to follow on myself... Am 08.06.20 um 16:44 schrieb Manfred Schwarb: [...]
So probably a case for "Closing The Tumbleweed Gap" ?
This can also be seen in other repositories, e.g. Application:Geo, where you have to install everything but the kitchen sink from there if you are in need of an application from Application:Geo, just because this repo seems TW oriented.
So to be a bit more constructive, what would be a way forward? Actually there are quite some interesting packages in TW which are missing in Leap, e.g. "qgis" which is a defacto reference application for dealing with geospatial tasks. So what to do? - an additional "contrib" repro for Leap which has some weaker standards in respect to acceptance/maintenance? - should "all" packages in TW end up in Leap? What are criteria to be selected for Leap? In the above case, "qgis" is in TW since 9 months but didn't make it into Leap 15.2. - being much more "aggressive" in pushing packages from specialized repos as filesystem, hardware, science, etc. into TW, and then into Leap? Is this actually desired? Thanks, Manfred -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (16)
-
Andreas Schwab -
Andrei Borzenkov -
Carsten Ziepke -
Jan Engelhardt -
Malcolm -
Manfred Schwarb -
Martin Wilck -
Michael Ströder -
Michal Kubecek -
Michal Suchánek -
Neal Gompa -
Ondřej Súkup -
Peter Simons -
Simon Lees -
Stasiek Michalski -
Werner LEMBERG