11:41 a.m.
Hello all.
Duplicate package of libquotient - libqmatrixclient - was reviewed,
accepted and pushed to stable repositories.
Not it cause conflicts.
libqmatrixclient must be untagged and removed from all Fedora releases.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
12:14 p.m.
On Wed, Jul 29, 2020 at 06:41:57PM +0200, Vitaly Zaitsev via devel wrote:
Hello all.
Duplicate package of libquotient - libqmatrixclient - was reviewed,
accepted and pushed to stable repositories.
Not it cause conflicts.
I guess you meant "Now" there?
libqmatrixclient must be untagged and removed from all Fedora releases.
We don't remove things from stable releases normally.
What exactly are the conflicts? Can you Obsolete/Provides whatever in
libquotient?
kevin
12:30 p.m.
On 29.07.2020 19:14, Kevin Fenzi wrote:
What exactly are the conflicts? Can you Obsolete/Provides whatever
in
libquotient?
libqmatrixclient is a very old version of libquotient (before the
upstream decided to rename it). Both of them provides the same files
(except of library versions).
If someone still need it, it should have compat- prefix, I think.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
12:33 p.m.
Vitaly,
Can you please explain what you mean by conflicts? They are in
completely different directories.
I am unaware of any policy that does not allow this, quaternion (by the
author of the library) has no release that can be built with libquotient
yet. Untagging libQMatrixClient will break quaternion, I have been
planing to obsolete libQMatrixClient in favor of libquotient as soon as
quaternion has a version that can be built with libquotient.
Regards,
Brendan Early
1:06 p.m.
On 29.07.2020 19:33, Brendan Early wrote:
Can you please explain what you mean by conflicts? They are in
completely different directories.
Libqmatrixclient is a very old version of libquotient. Compatibility
packages should have compat- prefix.
I am unaware of any policy that does not allow this, quaternion (by
the
author of the library) has no release that can be built with libquotient
yet.
Have you tried to build Git snapshots of Quaternion instead of regular
releases at least for Rawhide?
I have been
planing to obsolete libQMatrixClient in favor of libquotient as soon as
quaternion has a version that can be built with libquotient.
This is okay then. But it should be obsoleted by libquotient. Send me an
email when you decide to do this.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
3:50 p.m.
> Can you please explain what you mean by conflicts? They are in
> completely different directories.
Libqmatrixclient is a very old version of libquotient. Compatibility
packages should have compat- prefix.
- That is not a conflict. I do not understand what is conflicting.
- Untagging is an inappropriate action to take.
- 0.5.x (libqmatrixclient) is not "very old", it has been receiving updates and
0.6.x (libquotient) just had its first stable release last week.
- I agree that adding the compat suffix is best practice, but I do not believe that it
applies in this situation. When I introduced libqmatrixclient it was still stable and
libquotient was only a beta. The policy that requires this is called "Multiple
packages with the same base name" which is not the case in this situation. The name
"libqmatrixclient" is also already indicative of the package's version.
Have you tried to build Git snapshots of Quaternion instead of
regular
releases at least for Rawhide?
Quaternion is under active development. I would prefer that a potentially broken version
does not get branched.
This is okay then. But it should be obsoleted by libquotient. Send me
an
email when you decide to do this.
That is what I meant by that.
5:18 p.m.
On Wednesday, 29 July 2020 at 20:06, Vitaly Zaitsev via devel wrote:
On 29.07.2020 19:33, Brendan Early wrote:
> Can you please explain what you mean by conflicts? They are in
> completely different directories.
Libqmatrixclient is a very old version of libquotient. Compatibility
packages should have compat- prefix.
Not anymore. Please point to the relevant Packaging Guidelines entry if
you think otherwise.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
3:03 a.m.
Vitaly Zaitsev via devel wrote:
Libqmatrixclient is a very old version of libquotient. Compatibility
packages should have compat- prefix.
Independently of what the current packaging guidelines say about this
(apparently, "compat-" is not even a thing anymore there, see Rathann's
reply), it simply does not make sense to use any sort of prefixing or
suffixing to the package name when the old and the new library have
different package names (as in this case: libqmatrixclient vs. libquotient).
If the actual sonames are conflicting, then that needs to be dealt with (but
that would be an upstream issue then, they ought to use a different soname
if the libraries are not binary-compatible!), but it does not require
mangling the package name.
Kevin Kofler
10:11 a.m.
On 30.07.2020 10:03, Kevin Kofler wrote:
Independently of what the current packaging guidelines say about this
(apparently, "compat-" is not even a thing anymore there, see Rathann's
reply), it simply does not make sense to use any sort of prefixing or
suffixing to the package name when the old and the new library have
different package names (as in this case: libqmatrixclient vs. libquotient).
Previously it wasn't allowed to push different versions of the same
project into repositories. That's why Fedora Modularity was invented.
I see the this is permitted now, sorry for the noise.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
12:48 p.m.
On Thursday, 30 July 2020 at 17:11, Vitaly Zaitsev via devel wrote:
On 30.07.2020 10:03, Kevin Kofler wrote:
> Independently of what the current packaging guidelines say about this
> (apparently, "compat-" is not even a thing anymore there, see
Rathann's
> reply), it simply does not make sense to use any sort of prefixing or
> suffixing to the package name when the old and the new library have
> different package names (as in this case: libqmatrixclient vs. libquotient).
Previously it wasn't allowed to push different versions of the same
project into repositories. That's why Fedora Modularity was invented.
I see the this is permitted now, sorry for the noise.
I'm not sure where you got the idea that it wasn't permitted. It always
was, you just had to ensure the packages didn't conflict. The only thing
that changed some time ago is that the compat- prefix is no longer
required.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
5:01 a.m.
libqmatrixclient vs libquotient
Absolutely no conflict whatsoever. Different SONAME, different file/folder
names, different package names, different project name. Even if they came
from the same project, the old compat- naming scheme would not have applied.
5:48 a.m.
On Fri, Jul 31, 2020 at 12:01:53PM +0200, Michael Schwendt wrote:
libqmatrixclient vs libquotient
Absolutely no conflict whatsoever. Different SONAME, different file/folder
names, different package names, different project name. Even if they came
from the same project, the old compat- naming scheme would not have applied.
What about bringing old, possibly unmaintained library into Fedora?
It may contain unfixed security bugs. Not that I know of any, but it's
a possibility.
--
Tomasz Torcz Morality must always be based on practicality.
tomek(a)pipebreaker.pl — Baron Vladimir Harkonnen
9:15 a.m.
On Fri, 31 Jul 2020 12:48:44 +0200, Tomasz Torcz wrote:
What about bringing old, possibly unmaintained library into
Fedora?
It may contain unfixed security bugs. Not that I know of any, but it's
a possibility.
1) First it would need to pass the review process. Submitter _and_
reviewer both ought to notice that it is "old, possibly unmaintained"
software. In case of a lib, there's also the related question of "what
will use this lib?". Later it will be "what still uses this lib?" and
"are there alternatives or a successor?".
2) Once a package has been included in the package collection, "old,
possibly unmaintained" software is sort of a grey area. There are
thousands of packages in the collection, "possibly" with undiscovered
security issues. For those that are known to contain major vulnerabilities
and are unmaintained (like wxGTK2), it may be necessary to remove a
package from the collection.
3:52 a.m.
Vitaly Zaitsev via devel wrote:
Previously it wasn't allowed to push different versions of the
same
project into repositories. That's why Fedora Modularity was invented.
That is what the Modularity developers wanted you to believe. The fact is,
parallel-installable compatibility libraries have always been allowed, and
they are the best approach to this problem, because they allow applications
using the old and new library to be installed on the same system at the same
time (without workarounds such as chroots, containers, or even VMs), unlike
the mutually exclusive module versions in the Modularity approach.
Kevin Kofler
1386
days inactive
1388
days old
13 comments
7 participants
participants (7)
-
Brendan Early -
Dominik 'Rathann' Mierzejewski -
Kevin Fenzi -
Kevin Kofler -
Michael Schwendt -
Tomasz Torcz -
Vitaly Zaitsev