Bug 198836 - Review Request: freetype1 - FreeType 1.x compatibility library
Review Request: freetype1 - FreeType 1.x compatibility library
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul F. Johnson
Fedora Package Reviews List
:
: 212488 217479 (view as bug list)
Depends On:
Blocks: FE-ACCEPT 170936 185881 196519 217479
  Show dependency treegraph
 
Reported: 2006-07-13 18:58 EDT by Behdad Esfahbod
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-11 08:06:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Behdad Esfahbod 2006-07-13 18:58:02 EDT
Spec URL: http://www.cs.toronto.edu/~behdad/fedora/freetype1/freetype1.spec
SRPM URL: http://www.cs.toronto.edu/~behdad/fedora/freetype1/freetype1-1.4-0.1.pre.src.rpm
Description:

I removed FreeType 1.x stuff from the freetype package in core.  That happened when going from freetype-2.1.10 to freetype-2.2.1.  A few Extras packages depend on FreeType 1.x, hence this package.

%description
The FreeType engine is a free and portable TrueType font rendering
engine, developed to provide TrueType support for a variety of
platforms and environments. FreeType is a library which can open and
manages font files as well as efficiently load, hint and render
individual glyphs. FreeType is not a font server or a complete
text-rendering library.  The version 1.x of FreeType is obsolete.
New applications should use the more advanced FreeType 2.x library
packaged as freetype.
Comment 1 Rex Dieter 2006-07-13 20:04:07 EDT
Where does freetype-1.4pre come from?  The latest I can find is 1.3.1:
http://sourceforge.net/project/showfiles.php?group_id=3157&package_id=3068

I guess we would know how/where to find it, if you used a full URL in the
Source: field.
Comment 2 Rex Dieter 2006-07-13 20:06:35 EDT
And you should omit static libs (%_libdir/lib*.a) and %{_libdir}/lib*.la files.
Comment 3 Michael Schwendt 2006-07-14 10:23:56 EDT
> %package utils
> Summary: A collection of FreeType 1.x utilities
> Group: System Environment/Libraries
> Requires: %{name} = %{version}-%{release}
> # Upgrade path
> Provides: freetype-utils = 2.2.0-1
> Obsoletes: freetype-utils < 2.2.0-1

Very ugly. At the time this freetype-utils sub-package was
introduced, it should have started at 1.x, not 2.x.

You could still do that with a proper Epoch.
Comment 4 Behdad Esfahbod 2006-07-16 00:48:30 EDT
(In reply to comment #1)
> Where does freetype-1.4pre come from?  The latest I can find is 1.3.1:
> http://sourceforge.net/project/showfiles.php?group_id=3157&package_id=3068

Don't know.  It probably is rolled by someone specifically for Red Hat Linux /
Fedora.  I just got it from freetype-2.1.10 SRPM.
Comment 5 Behdad Esfahbod 2006-07-16 00:53:22 EDT
(In reply to comment #3)
> > %package utils
> > Summary: A collection of FreeType 1.x utilities
> > Group: System Environment/Libraries
> > Requires: %{name} = %{version}-%{release}
> > # Upgrade path
> > Provides: freetype-utils = 2.2.0-1
> > Obsoletes: freetype-utils < 2.2.0-1
> 
> Very ugly. At the time this freetype-utils sub-package was
> introduced, it should have started at 1.x, not 2.x.
> 
> You could still do that with a proper Epoch.

Right.  So, should I use Epoch instead?  Like:

Provides: freetype-utils = 1:1.4-0.1.pre
Comment 6 Behdad Esfahbod 2006-07-16 00:54:32 EDT
(In reply to comment #2)
> And you should omit static libs (%_libdir/lib*.a) and %{_libdir}/lib*.la files.

Correct.  The freetype package in Core is not dropping those.  Will fix both.
Comment 7 Rex Dieter 2006-07-16 09:22:09 EDT
Re: comment #4
If there exists no upstream freetype-1.4pre1, then I suggest you change to a
release that *does* exist.


Re: comment #5,
>So, should I use Epoch instead?  Like:
>Provides: freetype-utils = 1:1.4-0.1.pre

imo, yes, this is better. (though epochs should usually be avoided when/if
possible, I see no better alternative in this case to fix the previous hackage).
Comment 8 Behdad Esfahbod 2006-07-16 10:47:35 EDT
(In reply to comment #7)
> Re: comment #4
> If there exists no upstream freetype-1.4pre1, then I suggest you change to a
> release that *does* exist.

I don't agree.  This is about a compatibility library that was last developed
(the 1.x series) in 2000.  I strongly believe that we should just continue to
ship the exact same thing that we have been shipping so far in core, instead of
archeology.  There's absolute no advantage in switching over.
Comment 9 Rex Dieter 2006-07-16 11:06:51 EDT
(Justifications aside) my point is that *I*, as reviewer, won't approve of any
package for which there exists no (verifiable) upstream source.
Comment 10 Behdad Esfahbod 2006-07-16 12:10:33 EDT
(In reply to comment #9)
> (Justifications aside) my point is that *I*, as reviewer, won't approve of any
> package for which there exists no (verifiable) upstream source.

What do you suggest I do, given that changing source is not an option?
Comment 11 Ralf Corsepius 2006-07-17 01:50:41 EDT
(In reply to comment #10)
> What do you suggest I do, given that changing source is not an option?
There is an obvious solution:

Use the latest official tarball as basis and provide a patch against it.
Comment 12 Behdad Esfahbod 2006-07-17 14:34:01 EDT
I refuse to fix something that is not broken.  If you just want to verify the
tarball, you can compare it to the one in freetype-2.1.10 core package.

If the review cannot go through with the current tarball, I withdraw my request
and let someone else package freetype1.  A few Extras packages depend on it.

Thanks,
Comment 13 Matthias Clasen 2006-07-17 14:36:01 EDT
As I said to Behdad, if you really care about 6 year old tarballs that much, do
the work. Behdad did what you could expect from him by providing a package that
picks up exactly the bits that he dropped from Core.

Some Extras packages do depend on libttf, so either the maintainers of those
packages will have to fight to get this reviewed, or have to port their packages
away from libttf...
Comment 14 Behdad Esfahbod 2006-07-20 18:13:55 EDT
I fail to find any official upstream releases of FreeType 1.x.
Comment 15 Rex Dieter 2006-07-21 07:41:50 EDT
> I fail to find any official upstream releases of FreeType 1.x.

Here?
http://sourceforge.net/project/showfiles.php?group_id=3157&package_id=3068
Comment 16 Rex Dieter 2006-08-22 08:43:40 EDT
Re: comment #12:
> If the review cannot go through with the current tarball, I withdraw my request

That is the case (imo).  If you refuse to play by the rules (using verifiable,
upstream source), then follow through on your threat and withdraw the Review
Request (and close this bug).
Comment 17 Behdad Esfahbod 2006-08-22 14:41:59 EDT
(In reply to comment #16)
> Re: comment #12:
> > If the review cannot go through with the current tarball, I withdraw my request
> 
> That is the case (imo).  If you refuse to play by the rules (using verifiable,
> upstream source), then follow through on your threat and withdraw the Review
> Request (and close this bug).

This was not a threat.  And I appreciate if you don't call my acts like that.  I
removed freetype1 code from the Core package, so I tried to be nice and package
it for Extras.  If it's too much work for little to no benefit, I don't have the
time to do that.

I actually did download the tarball you linked to and it's sitting in my laptop
waiting for some attention.  But that doesn't mean much in this conversation...
Comment 18 Rex Dieter 2006-08-22 15:15:46 EDT
> This was not a threat.  And I appreciate if you don't call my acts 
> like that.

It was what it was, though I apologize for taking the too aggressive tone.  I 
was cranky that I had too many (inactive) bugs not getting fixed this morning, 
and I took a little of that out on you.

> I actually did download the tarball you linked to and it's sitting in 
> my laptop waiting for some attention. 

Thanks for the Extras (pun intended) effort. (:

Comment 19 Hans de Goede 2006-10-19 11:23:35 EDT
Hi all,

First of all apologies for hijacking this review, but it seems a bit stalled.
Some timeago davej send a mail to the FE list that he would dearly miss
MagicPoint, since davej is a nice guy and does tremendous work for the FC kernel
I thought I could do him a favour by unorphaning MagicPoint however it turns out
that MagicPoint requires freetype1, so here I am.

Behdad Esfahbod, thanks for creating and posting the freetype1 compat package, I
think it is great that you thought about possible troubles for FE when dropping
this from Core. However I also see that you are not an FE contributer at the
moment and thus need to go to the sponsering process. Is this the only package
you intend to submit and maintain in FE, or do you plan to submit other packages
too?

If this is the only one then it would maybe be better if someoneelse (me for
example) maintained freetype1 in FE, in that case I would like to ask you to be
my co-maintainer as I assume you no freetype infinetely better then I do so if I
get any bug reports against freetype which are about functional problems (not
packaging problems) then I could really use your help.

If you intend to submit more packages then you'll need a sponsor. Since I can
sponsor people and I know have a vested interest in getting freetype1 into FE,
let me offer myself as your sponsor in this scenario.

Either way I've already prepared a cleaned up and improved freetype1 package
with the following changes:
* Thu Oct 19 2006 Hans de Goede <j.w.r.degoede@hhs.nl> 1.4-0.2.pre
- Base on freetype-1.3.1.tar.gz + a patch with the changes contained
  in the 1.4pre tarbal found in previous Fedora Core freetype releases
- Cleanup and FE-ize the spec file
- Don't reautoconf as that doesn't seem nescesarry
- Fix (remove) use of rpath
- Don't include static libs and .la files
- Give the freetype1-utils Obsoletes and Provides an Epoch instead of
  using a 2.x version.

Do you know why the whole reautoconf thing was ever done in the first place?

You can get this new version from here:
http://people.atrpms.net/~hdegoede/freetype1.spec
http://people.atrpms.net/~hdegoede/freetype1-1.4-0.2.pre.src.rpm
Comment 20 Behdad Esfahbod 2006-10-19 12:16:26 EDT
(In reply to comment #19)
> Behdad Esfahbod, thanks for creating and posting the freetype1 compat package, I
> think it is great that you thought about possible troubles for FE when dropping
> this from Core. However I also see that you are not an FE contributer at the
> moment and thus need to go to the sponsering process. Is this the only package
> you intend to submit and maintain in FE, or do you plan to submit other packages
> too?

I'm actually sponsored by Daniel Veillard, but by all means, please go for it. 
I have enough packages to maintain in Core that I really appreciate a hand here.
 This bug is yours now.
Comment 21 Behdad Esfahbod 2006-10-19 12:18:08 EDT
As for the autoreconf, it's there because the tarball is really really old.  If
you remove that, make sure you do libtoolize at least.  We depend on a recent
libtool for libraries to work on all platforms.
Comment 22 Hans de Goede 2006-10-19 14:29:34 EDT
Ok, I'll take this through review and import it then.

Rex, can you do a formal review of the version I posted please? Thanks!
Comment 23 Rex Dieter 2006-10-19 14:45:13 EDT
I'm swamped temporarily, maybe next week.
Comment 24 Hans de Goede 2006-10-19 14:48:51 EDT
Okay, no problem I only named you because of your previous comments, who knows
maybe someone will beat you to it :)
Comment 25 Behdad Esfahbod 2006-10-26 20:18:43 EDT
*** Bug 212488 has been marked as a duplicate of this bug. ***
Comment 26 Paul F. Johnson 2006-11-12 07:29:24 EST
I can get on with it later today (just got to get the buildsys working again).
Comment 27 Hans de Goede 2006-11-23 09:42:22 EST
Paul, many thanks for offering to review this, but it seems it has fallen 
through the cracks, anytime on a review soon?

Thanks!
Comment 28 Paul F. Johnson 2006-11-25 18:45:44 EST
Sorry for the delay - had all sorts of problems at this end.

rpmlint - clean on all package (non main packages have no docs warnings, ignore)
mock - clean

REVIEW
License - is BSD-like a valid type?
Consistent use of macros
Spec in UTF-8, US English, Clear
No permission / ownership issues
Contains documentation (see above)
Contains reason for not using smp_make
Removes .la files
MD5s match for the tarballs
Contains clean, pre and postuns
No RPM dep issues

If you can confirm that BSD-like is a valid license, I'm happy.
Comment 29 Hans de Goede 2006-11-26 02:08:33 EST
Well rpmlint likes it, so I assume its a valid license, I took this from the
spec initially created by the core freetype maintainer.
Comment 30 Behdad Esfahbod 2006-12-01 11:59:05 EST
*** Bug 217479 has been marked as a duplicate of this bug. ***
Comment 31 Paul F. Johnson 2006-12-22 15:53:59 EST
APPROVED
Comment 32 Hans de Goede 2007-01-11 08:06:01 EST
Thanks, now that I'm sorta back online I've imported and build this, closing.

Note You need to log in before you can comment on or make changes to this bug.