Bug 220381 - Review Request: compat-flex - Legacy version of flex, a tool for creating scanners
Review Request: compat-flex - Legacy version of flex, a tool for creating sca...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ralf Corsepius
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-12-20 15:59 EST by Petr Machata
Modified: 2015-05-04 21:32 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-21 15:10:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
wtogami: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Petr Machata 2006-12-20 15:59:21 EST
Spec URL: http://people.redhat.com/~pmachata/flex-old.spec
SRPM URL: http://people.redhat.com/~pmachata/flex-old-2.5.4a-1.src.rpm
Description:

We are preparing to get reentrant flex (2.5.33) into Fedora Core. After the discussion with notting, we settled down on a following scenario: 

 * starting with FC7, the package flex will provide flex-2.5.33
 * in addition, flex-old will be provided, holding 2.5.4 branch of flex
 * the two packages don't conflict, it's possible to install them side by side

flex-old installs everything with the -old  suffix, e.g. /usr/bin/flex-old, /usr/lib/libfl-old.a.  Header file is in /usr/include/flex-old/FlexLexer.h, so that it's possible to request its inclusion via gcc's -I flag (dirs added with -I have precedence before system include directories).

The output of rpmlint is as follows:
$ rpmlint ../RPMS/i386/flex-old-2.5.4a-1.i386.rpm
W: flex-old devel-file-in-non-devel-package /usr/lib/libfl-old.a
W: flex-old devel-file-in-non-devel-package /usr/include/flex-old/FlexLexer.h

flex is of course development package itself, so the warnings should be ignored.
Comment 1 Jesse Keating 2006-12-20 16:09:05 EST
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?
Comment 2 Jason Tibbitts 2006-12-20 17:10:09 EST
Aren't packages like thus usually named compat-*?  There seems to be no
precedent for *-old.
Comment 3 Petr Machata 2006-12-21 03:45:08 EST
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.
Comment 4 Jesse Keating 2006-12-21 08:57:12 EST
(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.
Comment 5 Petr Machata 2006-12-21 12:51:19 EST
> 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.
Comment 6 Jason Tibbitts 2006-12-29 22:49:40 EST
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.)
Comment 7 Ralf Corsepius 2006-12-30 00:31:31 EST
(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>
Comment 8 Petr Machata 2007-01-05 12:17:28 EST
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.
Comment 9 Petr Machata 2007-01-05 12:24:23 EST
(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.
Comment 10 Ralf Corsepius 2007-01-05 23:48:14 EST
(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.
Comment 11 Petr Machata 2007-01-17 13:17:07 EST
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.)
Comment 12 Ralf Corsepius 2007-01-23 04:13:00 EST
FYI: http://gcc.gnu.org/ml/gcc/2007-01/msg00870.html
Comment 13 Petr Machata 2007-01-24 12:53:08 EST
Btw, I just commited flex 2.5.33 into raw hide.
Are there are any other comments regarding the compat-flex package?
Comment 14 Petr Machata 2007-02-02 04:00:35 EST
Another note... I realized flex can't have .so library, because binaries would
then be runtime-dependent on flex.
Comment 15 Ralf Corsepius 2007-02-02 05:17:42 EST
(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.

Comment 16 Ralf Corsepius 2007-02-02 06:07:21 EST
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.
Comment 17 Petr Machata 2007-02-02 12:26:44 EST
- 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
Comment 18 Ralf Corsepius 2007-02-05 10:14:52 EST
Sorry, somehow bugzilla has swallowed this:

APPROVED

Petr, do you have any further FE packages at review?
Comment 19 Petr Machata 2007-02-07 07:45:25 EST
Thanks Ralf.  I have no other extras packages, modulo the core->extras migrations.
Comment 20 Petr Machata 2007-03-21 13:53:53 EDT
New Package CVS Request
=======================
Package Name: compat-flex
Short Description: Legacy version of flex, a tool for creating scanners
Owners: pmachata@redhat.com
Branches:
InitialCC:
Comment 21 Petr Machata 2007-03-21 15:10:27 EDT
Thanks everyone, compat-flex build (id 30060) succeeded.

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