2:18 a.m.
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.
--
Cheap Linux CD's
http://mpeters.us/linux/
6:35 a.m.
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.
8:15 a.m.
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.
9:36 a.m.
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.
10:14 a.m.
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.
--
Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.667
loadavg: 0.78 0.37 0.16
11:02 a.m.
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.
11:16 a.m.
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?
11:47 a.m.
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? :)
--
Fedora Core release 3 (Heidelberg) - Linux 2.6.9-1.667
loadavg: 1.18 1.29 0.85
4:15 a.m.
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,
--
Ricardo Veguilla <veguilla(a)hpcf.upr.edu>
7100
days inactive
7101
days old
8 comments
3 participants
participants (3)
-
Michael A. Peters -
Michael Schwendt -
Ricardo Veguilla