What is the official policy about packages in Fedora Extras which marked as conflicting with eachother?
E.g. Sylpheed (dropped from Rawhide) and Sylpheed-claws share file names for main binary, manual page, pixmap file, desktop file. And since Sylpheed-claws is the feature-enhanced bleeding edge development fork of Sylpheed, there may be other conflicts. While this particular conflict could be resolved by renaming the files, this would be contrary to what upstream does.
As another example, gpgme03-devel and gpgme-devel. Used to building in clean build environments where only the needed build requirements are pulled in, there was no need to relocate either package and make it possible to install both at once.
I think there are other extras which conflict because they provide same or similar functionality, not limited to "leafnode" and "suck", "oidentd" and "pidentd" (core), "proftd" and "vsftpd anonftp" (core).
Where do we go from here?
On Fri, 2005-03-04 at 17:12 +0100, Michael Schwendt wrote:
What is the official policy about packages in Fedora Extras which marked as conflicting with eachother?
E.g. Sylpheed (dropped from Rawhide) and Sylpheed-claws share file names for main binary, manual page, pixmap file, desktop file. And since Sylpheed-claws is the feature-enhanced bleeding edge development fork of Sylpheed, there may be other conflicts. While this particular conflict could be resolved by renaming the files, this would be contrary to what upstream does.
Packages in Extras should not conflict with packages in Core, when we're effectively talking about the same package. If foo-bar is just a newer version of foo, then it needs to be updated in Core (or moved to extras, where it can be foo-bar).
As another example, gpgme03-devel and gpgme-devel. Used to building in clean build environments where only the needed build requirements are pulled in, there was no need to relocate either package and make it possible to install both at once.
Hmm. I think in the case of foo3 and foo, if they need to be installed at the same time, they need to follow the openssl example, and not conflict.
I think there are other extras which conflict because they provide same or similar functionality, not limited to "leafnode" and "suck", "oidentd" and "pidentd" (core), "proftd" and "vsftpd anonftp" (core).
In some cases, we might be able to use the alternatives system, so that "identd" and "ftpd" are what we actually use, and have the rpms "Provide" the alternatives name. Then, the user can use alternatives to switch between the options.
As usual, I'm open to suggestions on this.
~spot --- Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!
On Fri, 2005-03-04 at 10:45 -0600, Tom 'spot' Callaway wrote:
As another example, gpgme03-devel and gpgme-devel. Used to building in clean build environments where only the needed build requirements are pulled in, there was no need to relocate either package and make it possible to install both at once.
Hmm. I think in the case of foo3 and foo, if they need to be installed at the same time, they need to follow the openssl example, and not conflict.
openssl is somewhat different, there's no -devel for the older one. Usually providing two different versions of lib packages without conflicts is fairly trivial, but a bit less so for their -devel subpackages.
Michael Schwendt (bugs.michael@gmx.net) said:
What is the official policy about packages in Fedora Extras which marked as conflicting with eachother?
Conflicting packages are bad, period. Makes writing installers messy, as conflicts are done at the last stage of resolution.
They really should be avoided if at all possible.
I think there are other extras which conflict because they provide same or similar functionality, not limited to "leafnode" and "suck", "oidentd" and "pidentd" (core), "proftd" and "vsftpd anonftp" (core).
Are these real physical conflicts, or merely things that provide similar functionality?
Bill
On Fri, 4 Mar 2005 12:29:45 -0500, Bill Nottingham wrote:
What is the official policy about packages in Fedora Extras which marked as conflicting with eachother?
Conflicting packages are bad, period. Makes writing installers messy, as conflicts are done at the last stage of resolution.
They really should be avoided if at all possible.
I think there are other extras which conflict because they provide same or similar functionality, not limited to "leafnode" and "suck", "oidentd" and "pidentd" (core), "proftd" and "vsftpd anonftp" (core).
Are these real physical conflicts, or merely things that provide similar functionality?
Either. To be investigated. I just ran grep on the devel tree in CVS. proftpd package listing looks like it conflicts physically, also with old wuftpd.
gpgme-devel and gpgme03-devel (as well as sylpheed-claws and sylpheed) are physical conflicts.
$ rpmlsv gpgme-devel -rwxr-xr-x root root 2755 /usr/bin/gpgme-config -rw-r--r-- root root 47745 /usr/include/gpgme.h -rw-r--r-- root root 264428 /usr/lib/libgpgme-pth.a lrwxrwxrwx root root 22 /usr/lib/libgpgme-pth.so -rw-r--r-- root root 264290 /usr/lib/libgpgme-pthread.a lrwxrwxrwx root root 26 /usr/lib/libgpgme-pthread.so -rw-r--r-- root root 268276 /usr/lib/libgpgme.a lrwxrwxrwx root root 18 /usr/lib/libgpgme.so -rw-r--r-- root root 8034 /usr/share/aclocal/gpgme.m4 -rw-r--r-- root root 55012 /usr/share/info/gpgme.info.gz
As you can imagine, it could get ugly to relocate files like this and still make sure, API users still find them. gpgme03's only API/ABI user left is sylpheed-claws, which might catch up with main sylpheed GPGME 1.0 support soon. And then old gpgme03 can go for good.
Michael Schwendt (bugs.michael@gmx.net) said:
As you can imagine, it could get ugly to relocate files like this and still make sure, API users still find them. gpgme03's only API/ABI user left is sylpheed-claws, which might catch up with main sylpheed GPGME 1.0 support soon. And then old gpgme03 can go for good.
The feature enhanced development version only supports the old library? That's funny.
Frankly, I'm not sure what the point of having both in extras is; I would think just the main sylpheed package is enough.
Bill
On Fri, 4 Mar 2005 15:47:43 -0500, Bill Nottingham wrote:
As you can imagine, it could get ugly to relocate files like this and still make sure, API users still find them. gpgme03's only API/ABI user left is sylpheed-claws, which might catch up with main sylpheed GPGME 1.0 support soon. And then old gpgme03 can go for good.
The feature enhanced development version only supports the old library? That's funny.
Frankly, I'm not sure what the point of having both in extras is; I would think just the main sylpheed package is enough.
Extra features like support for Clamav, SpamAssassin, spell checking via aspell, many internal additions. I'd rather suggest renaming the few files in sylpheed-claws package, so it can coexist with stable sylpheed. Using Alternatives is overhead. And why should sylpheed-claws become /usr/bin/sylpheed? That is misleading if both packages can be installed at once.
On Fri, Mar 04, 2005 at 03:47:43PM -0500, Bill Nottingham wrote:
Michael Schwendt (bugs.michael@gmx.net) said:
As you can imagine, it could get ugly to relocate files like this and still make sure, API users still find them. gpgme03's only API/ABI user left is sylpheed-claws, which might catch up with main sylpheed GPGME 1.0 support soon. And then old gpgme03 can go for good.
The feature enhanced development version only supports the old library? That's funny.
Mea culpa. Sylpheed was in Core and I wanted gpgme-1.0 in Core so I patched it to use the newer gpgme and it was accepted upstream. Now sylpheed's out and we still don't have gpgme-1.0 in Core. (kmail uses it...)
Frankly, I'm not sure what the point of having both in extras is; I would think just the main sylpheed package is enough.
claws and sylpeed are a little further apart than branches, a bit closer than an actual fork. Someone might find it worthwhile to package each one separately. Right now, I don't think anyone's picked up the main sylpheed. If someone does, I think the right thing to do is rename files in sylpheed-claws to not conflict.
-Toshio
On Fri, 4 Mar 2005 13:13:49 -0800, Toshio Kuratomi wrote:
Mea culpa. Sylpheed was in Core and I wanted gpgme-1.0 in Core so I patched it to use the newer gpgme and it was accepted upstream. Now sylpheed's out and we still don't have gpgme-1.0 in Core. (kmail uses it...)
GnuPG 2 is not ready. Hence GPGME 1.0.x could not be built with the S/MIME part (aka GPGSM).
On Fri, Mar 04, 2005 at 10:42:18PM +0100, Michael Schwendt wrote:
On Fri, 4 Mar 2005 13:13:49 -0800, Toshio Kuratomi wrote:
Mea culpa. Sylpheed was in Core and I wanted gpgme-1.0 in Core so I patched it to use the newer gpgme and it was accepted upstream. Now sylpheed's out and we still don't have gpgme-1.0 in Core. (kmail uses it...)
GnuPG 2 is not ready. Hence GPGME 1.0.x could not be built with the S/MIME part (aka GPGSM).
True. But gpgme doesn't have a hard requirement on gnupg 2. In line with the two steps forward, one step backwards philosophy, I'd be happy with a gpgme-1 that only uses gnupg-1 and add S/Mime features when gnupg 2 is ready. This gets us a kmail with some signing support. OTOH, I mainly want to use gpgme in my code, not for any mailer. So for me, Extras is good enough.
-Toshio
On Fri, 4 Mar 2005 16:52:40 -0800, Toshio Kuratomi wrote:
Mea culpa. Sylpheed was in Core and I wanted gpgme-1.0 in Core so I patched it to use the newer gpgme and it was accepted upstream. Now sylpheed's out and we still don't have gpgme-1.0 in Core. (kmail uses it...)
GnuPG 2 is not ready. Hence GPGME 1.0.x could not be built with the S/MIME part (aka GPGSM).
True. But gpgme doesn't have a hard requirement on gnupg 2. In line with the two steps forward, one step backwards philosophy, I'd be happy with a gpgme-1 that only uses gnupg-1 and add S/Mime features when gnupg 2 is ready. This gets us a kmail with some signing support. OTOH, I mainly want to use gpgme in my code, not for any mailer. So for me, Extras is good enough.
Last time I looked, kmail was built with an internal GPGME 0.4.4 copy, and its OpenPGP features worked for me.
$ rpmlsv kdepim |grep -i gpgme -rwxr-xr-x root root 787 /usr/lib/libgpgme++.la lrwxrwxrwx root root 19 /usr/lib/libgpgme++.so.0 -rwxr-xr-x root root 228304 /usr/lib/libgpgme++.so.0.0.0 -rwxr-xr-x root root 906 /usr/lib/libqgpgme.la lrwxrwxrwx root root 18 /usr/lib/libqgpgme.so.0 -rwxr-xr-x root root 20048 /usr/lib/libqgpgme.so.0.0.0 drwxr-xr-x root root 0 /usr/share/doc/HTML/en/kdepim-apidocs/libkdenetwork/qgpgme drwxr-xr-x root root 0 /usr/share/doc/HTML/en/kdepim-apidocs/libkdenetwork/qgpgme/html
On Sat, Mar 05, 2005 at 03:02:18AM +0100, Michael Schwendt wrote:
Last time I looked, kmail was built with an internal GPGME 0.4.4 copy, and its OpenPGP features worked for me.
$ rpmlsv kdepim |grep -i gpgme -rwxr-xr-x root root 787 /usr/lib/libgpgme++.la lrwxrwxrwx root root 19 /usr/lib/libgpgme++.so.0 -rwxr-xr-x root root 228304 /usr/lib/libgpgme++.so.0.0.0 -rwxr-xr-x root root 906 /usr/lib/libqgpgme.la lrwxrwxrwx root root 18 /usr/lib/libqgpgme.so.0 -rwxr-xr-x root root 20048 /usr/lib/libqgpgme.so.0.0.0 drwxr-xr-x root root 0 /usr/share/doc/HTML/en/kdepim-apidocs/libkdenetwork/qgpgme drwxr-xr-x root root 0 /usr/share/doc/HTML/en/kdepim-apidocs/libkdenetwork/qgpgme/html
Oops. I've been misreading bug number 136533, which is actually asking only for Certificate Handling, not all OpenPGP support.
This brings up a new question, though. What are good justifications for using an internal library vs creating a system one? In this case, I think the internal library solves these problems:
1) Allows Core to be updated with a feature enhanced (gnuPG2) version from Extras. 2) Brings gpgme support to kmail without fussing with another package that is presently only needed by kmail. A) Doesn't apply in this case, but could help resolve version conflicts. (Example is sylpheed/claws gpgme requirements. Because claws requires gpgme03 to compile, creating a gpgme03 package is not enough; we also need the -devel package which conflicts with gpgme-1.0. Compiling against an internal gpgme03 would solve this.)
But it has these problems: 1) Increased size for someone who installs gpgme from Extras. A) Extras packages can use gpgme. Mixed bag as Core's gpgme would be built without S/MIME. 2) kmail does not get S/MIME features when gpgme from Extras is installed. 3) kmail does not get updated bugfixes/security fixes unless the kdepim packager updates to new gpgme versions (In this case, gpgme is version 1.0.2 and kmail is using 0.9.. only four versions out of date.)
Here are some ideas for guidelines: Applications should have local, internal copies of libraries if: 1) It is the best way to resolve a version conflict with a libary update that requires API changes because the two versions do not have parallel installable devel files (sylpheed-claws). 2) The application is in Core and the library would conflict with another library package in Extras that cannot move to Core. Reasons for this could include: A) Library in Extras is deemed unstable for inclusion in Core but a feature reduced version/other version will work. (kdepim/kmail)
When a package uses a local, internal library it should: 1) Be listed somewhere (fedoraproject.org/wiki page?) as using a local, internal version of the library with version and reason.
Open question: How much burden does the maintainer of the package with a local, internal library carry for updating the internal library? Who else would carry it if not the maintainer of the package? Can automated tools to tell of updates to the main library package help the package maintainer?
-Toshio
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Michael Schwendt -
Tom Callaway -
Toshio Kuratomi -
Ville Skyttä