Bug 1218707

Calibre is very sensitive when it comes to versions.
And yes. Some packages in BuildRequires are not required for the build itself. But as required. And whether a package is available, and in the correct version, is only displayed in this way.
So leave your requrest alone!

This does not explain anything. What does it mean 'very sensitive when it comes to versions'?

I have explained it. What's not to understand?
Calibre requires the specified packages and versions. Why should you reduce them? I don't see the point, but rather a danger. And I've been maintaining the package since 2015 or longer?
I took over the package when it was outdated and not running. It's been running ever since. Is that not acceptable?
It's not the first time that someone from Suse has come along after several years and wanted to change something.
Again, it has been running for 10 years now without any errors.
If you want to do something, then you should rather update the old and dead packages of Leap. And not generate problems unnecessarily.
And again. Not all packages are necessary for building. That is true. But are necessary in exactly the version to run. And there is no way to see if a package is outdated and needs to be updated during the build.

It cannot be included in Leap because these libraries conflict with core libraries from SLE. The package runs with these excessive dependencies stripped.

What specifically is the danger you are talking about?

Upstream requires these versions. I wonder why?
Update the other packages in Leap to the required version. Especially the ancient and deprecated Python(I know the problem with Sales) version 2 is dead. Version. 3.6, 3.7 and probably also 3.8 by now. That's the problem and not calibre!
And if you don't want to accept that, then take calibre from flatpack. That's the future goal of Suse anyway.

That's clearly not what the upstream requirement is. The package builds and runs with these build requires removed, without any patching of version checks.

I was the maintainer of calibre before Eric (and at the time we did have a working calibre that was up to date) and probably the last one to make any effort of maintaining calibre in Leap. Maybe I can say something helpful, hopefully?

I have followed Eric's work and he did a great job. I have also seen that at imes it was a bumpy ride and the at times it seems impossible to continue having a package in Tumbleweed. I get it that he wants to stick to the dependencies that upstream claims are needed. It makes maintaining calibre doable. Yes, the dependencies are excessive, but maintaining calibre is tough. The flatpak is just a repackaging of the official tarball. They don't even try compiling it themselves.

I would say that a submitrequest is not enough. Michal, if you want this, I would say Eric needs to know this does not increase his burden. This means you have to commit to fixing what breaks because of these changes.

I would say: a leap package is basically doing a fork once a year and use the beta phase to solve issues. Maintainance would be backporting hardware support and possibly security bugs. Is it not possible to try? And if it doesn't work, make it easy to revert?

Can you both not cooperate instead of this entrenched discussion?

(In reply to Michal Suchanek from comment #6)
> That's clearly not what the upstream requirement is. The package builds and
> runs with these build requires removed, without any patching of version
> checks.

Tell me. Don't you want to understand? Or can't you understand it?
One last time.
These are necessary packages that are needed later for error-free operation. And there is no other way to check their existence beforehand.
First find the right requirements and learn how to build packages.

(In reply to Cor Blom from comment #7)

> I have followed Eric's work and he did a great job. I have also seen that at
> imes it was a bumpy ride and the at times it seems impossible to continue
> having a package in Tumbleweed. I get it that he wants to stick to the
> dependencies that upstream claims are needed. It makes maintaining calibre
> doable. Yes, the dependencies are excessive, but maintaining calibre is
> tough. The flatpak is just a repackaging of the official tarball. They don't
> even try compiling it themselves.

One of the reasons why maintaining Calibre is tough is that Eric's way of communication turns away potential contributors to the package.

> I would say that a submitrequest is not enough. Michal, if you want this, I

I have built the package on Leap, and tested that it works. The request addresses a specific problem (together with updates of packages that are *really* used by calibre): calibre is currently not buildable on Leap.

> would say Eric needs to know this does not increase his burden. This means

How can it?

Nobody is forced to do anything about any package.

The change does not affect Factory, the packages will not vanish from there if Calibre does no longer build-depend on them.

It does in fact decrease burden in a very specific way: There is no need to maintain that very special project for building Calibre on Leap, and solving potential problems resulting from users randomly updating a bunch of libraries to install Calibre. It can be added to Leap now.

> you have to commit to fixing what breaks because of these changes.
> 
> I would say: a leap package is basically doing a fork once a year and use
> the beta phase to solve issues. Maintainance would be backporting hardware
> support and possibly security bugs. Is it not possible to try? And if it
> doesn't work, make it easy to revert?

Isn't even trying exactly what is rejected here?
 
> Can you both not cooperate instead of this entrenched discussion?

I wonder why we can't, indeed.

(In reply to Eric Schirra from comment #8)
> (In reply to Michal Suchanek from comment #6)
> > That's clearly not what the upstream requirement is. The package builds and
> > runs with these build requires removed, without any patching of version
> > checks.
> 
> Tell me. Don't you want to understand? Or can't you understand it?
> One last time.
> These are necessary packages that are needed later for error-free operation.

Necessary in what way? I do not see any need for them.

You can handwave that maybe potentially something somewhere in calibre will break when one of these package is lower version.

I can equally handwave that maybe potentially something somewhere in the hundreds of other packages on the system something might break when these packages are updated.

That gets us nowhere. What specific problem does requesting these package version address? If there is a specific problem you can request the package to be upgraded, and maintainer of the package can consider upgrading it.

It's not like even in Factory all the package versions suggested by upstream are available as evidenced by comments in the spec file about upstream using later version. Yet you do not go and upgrade the package in Factory, you make do with whatever is there.

But when I make do with whatever is in Leap suddenly that's bad. I see a double standard here.

@Michal
Leave it alone!
Unfortunately, you don't understand!