Bug 220381

Any particular reason why this has to be in Core, especially since we're merging
core and extras?  Couldn't this go directly into Extras?

Aren't packages like thus usually named compat-*?  There seems to be no
precedent for *-old.

jkeating: Other core components have their compat- package in core, too. E.g.
compat-db, compat-gcc family, compat-slang.

jason: It occured to me that -compat packages are libraries, but yes, now I see
there are also tools.  I adjusted the files:
Spec URL: http://people.redhat.com/~pmachata/compat-flex.spec
SRPM URL: http://people.redhat.com/~pmachata/compat-flex-2.5.4a-1.src.rpm

Note that everything still installs with *postfix* compat.  It seems more
natural to me to have e.g. libfl-compat.a instead of libcompat-fl.a, and
flex-compat will be offered on commandline when tab-completing flex.

(In reply to comment #3)
> jkeating: Other core components have their compat- package in core, too. E.g.
> compat-db, compat-gcc family, compat-slang.

Yes, but all of these are moving to Extras with the merger.  Unless there is
specific reason (needed to build something else) for this new package to go into
Core, it must go into Extras instead.  I'm not interested in
reviewing/importing/building into core, just to move/review/build it in the new
merged land a few months later.

> Yes, but all of these are moving to Extras with the merger.

Oh, I idn't know that.  So I'll have to set up extras account sooner or later. 
Good to know.

> Yes, but all of these are moving to Extras with the merger.  Unless there is
> specific reason (needed to build something else) for this new package to go 
> into Core, it must go into Extras instead.

Well, that will turn out.  The whole point of providing compat flex is that the
changes between 2.5.4 and 2.5.33 were very internal, and there are lots of them.
 I don't want to be stuck with the same ancient version of flex forever, .33 has
interesting features, and people are requesting it for some time already.  But
on the other hand, I don't dare upgrade without a fallback.  So some components
actually may end up with BuildRequires: compat-flex, although this should be
rare, and hopefully temporary.

This builds fine for me; a few comments:

rpmlint says:

W: compat-flex devel-file-in-non-devel-package /usr/include/flex-compat/FlexLexer.h
  I think this is OK; the whole point of flex is to produce C output which
requires this header.

W: compat-flex devel-file-in-non-devel-package /usr/lib64/libfl-compat.a
  Static libraries are generally frowned upon, but I don't know enough about
just how flex is used to say whether this is completely unacceptable.

The makeinstall macro should not be used unless there is no other choice.  Does
the preferred "make install DESTDIR=%{buildroot}" not work?

What's the purpose of the fine command at the end of %install with no action?  I
guess it's just debugging.

You should follow the recommendations from
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets for installing the
info files.  Specifically, you don't need the loop (there's only the one .info
file anyway) and you should really have the "|| :" bit there so no-documentation
installs don't break.

Your comment about needing to set up an extras account makes me think that
you'll need to be sponsored; if so, this ticket should additionally block
FE-NEEDSPONSOR.  (I can offer sponsorship, but I'm unsure about the static
library issue at this point.)

(In reply to comment #6)
> This builds fine for me; a few comments:

> W: compat-flex devel-file-in-non-devel-package /usr/lib64/libfl-compat.a
>   Static libraries are generally frowned upon, but I don't know enough about
> just how flex is used to say whether this is completely unacceptable.
Well, libfl basically provides a single function. One, most real world
lex-scanners normally implement themselves (i.e. link against statically) and
won't use anyway.

However, what is an issue, is the name of this library: libfl-compat.a.

This will break all packages because they expect to link against libfl. IMO, it
must remain libfl. 

Similar considerations apply to the location of FlexScanner.h.

I.e. instead of playing games with directories named "compat" and renaming libs,
I'd prefer to see the flex's headers and link-libraries files (*.h,*.a) to be
installed into a versioned directory, e.g. 
%{libdir}/flex-<version> 
%{includedir}/flex-<version>

Thanks for input, folks.  I posted updated files to the same url.  My comments
follow.

> libfl basically provides a single function
The library provides the function 'main'.  It's useful for linking with pure
scanner, for testing purposes I suppose.  I have never used it personally, but
it has been part of flex' interface for ages.  It technically can be shared,
however strange does it look to have a shared library with 'main' inside.  If
this would be showstopper, I'll make it shared, no problem here.

> However, what is an issue, is the name of this library
I doubt any package links with -lfl at all.  The library is useful for
development of lexer.  I think it will be more often fired from command line
than from script, thus I chose rather less invasive variant "-lfl-compat", as
opposed to "-lfl -L/usr/lib/flex-somesuffix".

> The makeinstall macro should not be used unless there is no other choice.
> Does the preferred "make install DESTDIR=%{buildroot}" not work?
No, the Makefile inside the flex-2.5.4a doesn't honor the DESTDIR variable.

> installing the info files
Got those fixed.  There were more problems, such as file names and infodir entry
name.

> prefer to see the flex's headers [...] installed into a versioned directory
Yes, using version number may be better idea.  I'll give it a thought.  Maybe it
would make more sense to rename also the binaries and relevant files.

(In reply to comment #6)
> Your comment about needing to set up an extras account makes me think that
> you'll need to be sponsored; if so, this ticket should additionally block
> FE-NEEDSPONSOR.  (I can offer sponsorship, but I'm unsure about the static
> library issue at this point.)

Thanks, I gladly accept that.  I added FE-NEEDSPONSOR.  Let's sort out the
remaining questions (comment #8) and we can move ahead.

(In reply to comment #8)
> Thanks for input, folks.  I posted updated files to the same url.  My comments
> follow.
> 
> > libfl basically provides a single function
> The library provides the function 'main'.  It's useful for linking with pure
> scanner, for testing purposes I suppose.
Yes and no. The real function that matters is yywrap()

It's the fall-back/default yywrap lex-generated scanners use if the scanner
doesn't provide one of its own. Most real-world scanner do and there do not link
against libfl.

>
> > However, what is an issue, is the name of this library
> I doubt any package links with -lfl at all. 
Sorry, you're in error.

- All flex-based packages using the default yywrap do need to link against it.
You so far  don't see this, because they link against it statically.

- All autoconf scripts using AC_PROG_LEX link against it.

> I have never used it personally
But I have and still am, for more than a decade.

> The library is useful for
> development of lexer.  I think it will be more often fired from command line
> than from script, thus I chose rather less invasive variant "-lfl-compat", as
> opposed to "-lfl -L/usr/lib/flex-somesuffix".
I have to disagree again.

Oh I see. What happened here is that I misread the output of objdump, only
noticing the first object with `main' function inside.  My bad.

I updated the spec to place compat libfl into /usr/lib/flex-2.5.4a/libfl.a, and
the include file into /usr/include/flex-2.5.4a/FlexLexer.h  If one wants to use
these files, she has to set up LDFLAGS's -L and CPPFLAGS' -I, but the commands
themselved remain intact.

(Sorry it took me so long to reply, I was ill last week.)

FYI: http://gcc.gnu.org/ml/gcc/2007-01/msg00870.html

Btw, I just commited flex 2.5.33 into raw hide.
Are there are any other comments regarding the compat-flex package?

Another note... I realized flex can't have .so library, because binaries would
then be runtime-dependent on flex.

(In reply to comment #14)
> Another note... I realized flex can't have .so library, because binaries would
> then be runtime-dependent on flex.
You'd have to split the package into run-time/devel/static to get this working,
but I do agree, this isn't very useful for flex-old/compat-flex.

Let's stay with one package and static libs only in this particular case.

These comments are based on
http://people.redhat.com/~pmachata/compat-flex-2.5.4a-1.src.rpm

# rpm -qlp compat-flex-2.5.4a-1.i386.rpm
/usr/bin/flex++-2.5.4a
/usr/bin/flex-2.5.4a
/usr/include/flex-2.5.4a/FlexLexer.h
/usr/lib/flex-2.5.4a/libfl.a
/usr/share/doc/compat-flex-2.5.4a
/usr/share/doc/compat-flex-2.5.4a/COPYING
/usr/share/doc/compat-flex-2.5.4a/NEWS
/usr/share/doc/compat-flex-2.5.4a/README
/usr/share/info/flex-2.5.4a.info.gz
/usr/share/man/man1/flex++-2.5.4a.1.gz
/usr/share/man/man1/flex-2.5.4a.1.gz

MUSTFIX:
- Package must own
/usr/lib/flex-2.5.4a
/usr/include/flex-2.5.4a

- BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
Please change this to the current FE conventions.

CONSIDER
- I think this package should contain a small README.fedora, which outlines what
it is and how it is supposed to be used (mentioning 
-I/usr/include/flex-2.5.4a and -L/usr/lib/flex-2.5.4a)


Please decide upon the final name of this package, update your srpm once more,
add a corresponding URL here in bugzilla and, provided you address the issues
mentioned here-in, I'd approve this package.

- Package now owns
/usr/lib/flex-2.5.4a
/usr/include/flex-2.5.4a

BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

- README.fedora written, available in srpm, and for convenience also here:
http://people.redhat.com/~pmachata/README.fedora

- The package will be called compat-flex, relevant files are here:
http://people.redhat.com/~pmachata/compat-flex.spec
http://people.redhat.com/~pmachata/compat-flex-2.5.4a-1.src.rpm

Sorry, somehow bugzilla has swallowed this:

APPROVED

Petr, do you have any further FE packages at review?

Thanks Ralf.  I have no other extras packages, modulo the core->extras migrations.

New Package CVS Request
=======================
Package Name: compat-flex
Short Description: Legacy version of flex, a tool for creating scanners
Owners: pmachata
Branches:
InitialCC:

Thanks everyone, compat-flex build (id 30060) succeeded.