I discovered I needed these two packages to get gnomesword2 to build in FC3.
I have since encountered other people with other software that needs the older shared libraries, such as monodoc.
Attached are spec files that are based on the FC2 spec files for those packages - it would great if *someone* who is a Fedora Extras would be willing to adopt them for Fedora Extras since FC3 ships versions that are too new for some software. All the build/install dependencies they need are already in FC2 (well, the compat-gtkhtml3 requires the compat- libgal2, but ...)
Thanks. It will make life for some people easier if it can be done.
Just a comment on some package details:
On Sun, 14 Nov 2004 08:18:31 +0000, Michael A. Peters wrote:
Summary: gtkhtml library compatability version Name: compat-gtkhtml3 Version: 3.0.10 Epoch: 0 Release: %{epoch}.%{my_build}
"Epoch" is really just an added method to influence RPM version-release comparison. A package with an epoch higher than the epoch in any other package is considered "newer" (=higher overall version), regardless of %version-%release. Expanding %epoch in %release doesn't make sense. Let your packages start at "Release: 1" and increase the release with every package revision. When the software version is upgraded, it is common to restart release at 1.
Explicit "Epoch: 0" has been used in order to work around epoch promotion problems in old versions of RPM up to Red Hat Linux 8.0. When a package is not built for those distributions, explicit Epoch is not needed.
BuildRequires: compat-libgal2-devel >= 0:1.99.10 Requires: compat-libgal2
Dependence on libgal2 is not automatic already?
%package devel Summary: Libraries, includes, etc to develop gtkhtml applications Group: Development/Libraries Requires: %{name} = %{version}-%{release}
When explicit "Epoch: 0" is used, above should read: Requires: %{name} = %{epoch}:%{version}-%{release}
Requires: compat-libgal2-devel >= 0:1.99.9
Above it's 1.99.10.
%files -f gtkhtml-3.0.lang %defattr(-, root, root) %doc AUTHORS ChangeLog NEWS README COPYING TODO %{_libdir}/*.so.* %{_libdir}/*.so.*
Duplicate.
%{_libdir}/gtkhtml/*.so %{_libdir}/bonobo/servers/*.server %{_datadir}/gtkhtml-3.0
Missing: %dir %{_libdir}/gtkhtml
I see it's also missing in FC3 package.
On 11/14/2004 04:35:10 AM, Michael Schwendt wrote:
Just a comment on some package details:
On Sun, 14 Nov 2004 08:18:31 +0000, Michael A. Peters wrote:
Summary: gtkhtml library compatability version Name: compat-gtkhtml3 Version: 3.0.10 Epoch: 0 Release: %{epoch}.%{my_build}
"Epoch" is really just an added method to influence RPM version-release comparison. A package with an epoch higher than the epoch in any other package is considered "newer" (=higher overall version), regardless of %version-%release. Expanding %epoch in %release doesn't make sense.
Last time I read the packaging guidelines - Fedora.us wanted the epoch specified in the release tag. Using the %{epoch} ensures that happens and matches the real epoch.
Furthermore, they wanted it to be the first number.
They may have changed the guidelines though - if you ask me, they were WAY to complex. Not impossible to understand, but too complex nonetheless.
On Sun, 14 Nov 2004 14:15:59 +0000, Michael A. Peters wrote:
Summary: gtkhtml library compatability version Name: compat-gtkhtml3 Version: 3.0.10 Epoch: 0 Release: %{epoch}.%{my_build}
"Epoch" is really just an added method to influence RPM version-release comparison. A package with an epoch higher than the epoch in any other package is considered "newer" (=higher overall version), regardless of %version-%release. Expanding %epoch in %release doesn't make sense.
Last time I read the packaging guidelines - Fedora.us wanted the epoch specified in the release tag.
Never.
Furthermore, they wanted it to be the first number.
Never.
The prefix 0.fdr has nothing to do with the Epoch. It ensures that any package merged into Fedora Core would win version-release comparison.
They may have changed the guidelines though -
It's unchanged.
if you ask me, they were WAY to complex. Not impossible to understand, but too complex nonetheless.
There's a tendency towards making "Epoch: 0" fully optional again in Fedora Extras, as an explicit Epoch is no longer needed.
On Sun, 14 Nov 2004 16:36:12 +0100, Michael Schwendt wrote:
There's a tendency towards making "Epoch: 0" fully optional again in Fedora Extras, as an explicit Epoch is no longer needed.
And this has been in the fedora.us QA checklist for a long time:
Epoch
* can be optionally defined "0" or omitted entirely.
Not to be confused with the necessity to add Epoch to versioned dependencies.
On 11/14/2004 08:14:35 AM, Michael Schwendt wrote:
And this has been in the fedora.us QA checklist for a long time:
OK. That's fine - I don't package for fedora, my understanding from reading their docs was that with the exception to updated RH packages - they wanted the epoch in the release tag, I think to make it easy to see the epoch from the stand alone package.
Browsing the repository - they have an aweful lot of packages that start with a 0 in the release tag - which would seem to confirm that they are doing exactly what I did by expanding epoch in the release tag.
On 11/14/2004 07:36:12 AM, Michael Schwendt wrote:
Last time I read the packaging guidelines - Fedora.us wanted the
epoch
specified in the release tag.
Never.
Furthermore, they wanted it to be the first number.
Never.
The prefix 0.fdr has nothing to do with the Epoch. It ensures that any package merged into Fedora Core would win version-release comparison.
I just looked through the doc again - you're right. It had been awhile since I read it, I don't package for Fedora (hence my request for someone who does ...). Their scheme though is rather complex - I guess to overcome shortcoming in rpm's versioning - but still overly complex.
It's probably vepoch I was remembering, but not having read the docs - well anyway, the epoch in the release tag makes sense to me because it gives a visual representation of what the epoch is just by looking at the file.
I'm not suggesting Fedora change things, but epoch makes sense, a complex release scheme, and vepoch - and there you have it.
Oh well.
So - any fedora extras people (who know the release scheme ;) want to package these for extras?
On Sun, 14 Nov 2004 17:16:08 +0000, Michael A. Peters wrote:
The prefix 0.fdr has nothing to do with the Epoch. It ensures that any package merged into Fedora Core would win version-release comparison.
Their scheme though is rather complex - I guess to overcome shortcoming in rpm's versioning - but still overly complex.
At least the package naming and versioning guidelines are documented at all. ;)
It's probably vepoch I was remembering, but not having read the docs -
The "versioned specific epoch" (vepoch) is a different concept. Basically, it's just an ordinary most significant number in the %release field (which can followed by an arbitrary part to its right). which to increment with every package revision. It's unrelated to RPM's %epoch. And the documentation is clear on that.
Example: Release: 5.1-0.fdr.4.2
5.1 = software version 0.fdr = fedora.us specific prefix 4 = actual package release number = vepoch 2 = Fedora Core 2
The vepoch is more than a simple release number, since it is also used to deal with upstream versioning schemes which break RPM version comparison (e.g. weird alpha/beta/rc/snapshot version names):
Release: 5.1-0.fdr.0.1.beta3.2
5.1 = software version first part (!) 0.fdr = fedora.us specific prefix 0.1 = vepoch scheme for pre-releases, 1 = actual package revision beta3 = software version postfix ==> 5.1beta3 is full version 2 = Fedora Core 2
Release: 5.1-0.fdr.0.2.beta3.2
5.1 = software version first part 0.fdr = fedora.us specific prefix 0.2 = vepoch scheme for pre-releases, 2 = actual package revision beta3 = software version postfix ==> 5.1beta3 is full version 2 = Fedora Core 2
Naming the package 5.1beta3-0.fdr.1 would make an upgrade to final 5.1-0.fdr.1 impossible without increasing the real %epoch, because "5.1beta3" > "5.1". For that final release, in fedora.us scheme, vepoch would simply turn from 0.x to x as in first example.
well anyway, the epoch in the release tag makes sense to me because it gives a visual representation of what the epoch is just by looking at the file.
Duplicating %epoch in %release would only add confusing complexity. Tools like Yum display the Epoch in package versions as %epoch:%version-%release. This adds enough confusion already for users who need libfoo.i386 1:1.2 and only find libfoo-1.2.
I'm not suggesting Fedora change things, but epoch makes sense, a complex release scheme, and vepoch - and there you have it.
Oh well.
So - any fedora extras people (who know the release scheme ;) want to package these for extras?
Probably the same people who would step forward and also package and maintain gnomesword2 and monodoc and "other software that needs the older shared libraries" for Fedora Extras? :)
On Sun, 2004-11-14 at 08:18 +0000, Michael A. Peters wrote:
I discovered I needed these two packages to get gnomesword2 to build in FC3.
Wouldn't be easier to compile gnomesword2 against the newer libs?
I have since encountered other people with other software that needs the older shared libraries, such as monodoc.
Yes, but since the Novel/Ximian guys like to develop against the stable releases (more specifically, against the libraries shipped with the stable release), monodoc will probably use the newer libs now that FC3 was released.
Attached are spec files that are based on the FC2 spec files for those packages - it would great if *someone* who is a Fedora Extras would be willing to adopt them for Fedora Extras since FC3 ships versions that are too new for some software. All the build/install dependencies they need are already in FC2 (well, the compat-gtkhtml3 requires the compat- libgal2, but ...)
In general, I don't think adding compatibilty libraries should be done unless there is no other alternative. The effort required to mantained them, etc will probably be better employed porting the applications to the new libraries.
Regards,
-
Michael A. Peters -
Michael Schwendt -
Ricardo Veguilla