List Info

Thread: libopts




libopts
user name
2006-12-22 03:00:04
The libopts package has no owners.list entry. 
It's files were cvs rm'ed a while back: 

revision 1.4
date: 2006/11/02 21:21:57;  author: pfj;  state: dead; 
lines: +0 -0

Removing package - now part of autogen
        libopts/Makefile libopts/import.log
libopts/FC-5/Makefile
        libopts/FC-5/branch libopts/FC-5/libopts.spec
        libopts/FC-5/sources libopts/FC-6/Makefile
libopts/FC-6/branch
        libopts/FC-6/libopts.spec libopts/FC-6/sources
        libopts/devel/Makefile libopts/devel/libopts.spec
        libopts/devel/sources

Of course since there is no bugzilla component and pfj
doesn't seem to
be around, it's hard to know what is going on... 

unless someone tells me otherwise I am going to place a
dead.package
file in libopts/FC-5/, libopts/FC-6, libopts/devel/ and mark
it as
Retired and request it's removal from the repos. 
(I will do this tomorrow)

Did it really become a part of autogen on all those branches
at the
same time? Should a owners.list entry be made for it anyhow?


kevin
-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list
libopts
user name
2006-12-22 05:54:52
On Thu, 2006-12-21 at 20:00 -0700, Kevin Fenzi wrote:
> The libopts package has no owners.list entry. 
> It's files were cvs rm'ed a while back: 
> 
> revision 1.4
> date: 2006/11/02 21:21:57;  author: pfj;  state: dead; 
lines: +0 -0
> 
> Removing package - now part of autogen
>         libopts/Makefile libopts/import.log
libopts/FC-5/Makefile
>         libopts/FC-5/branch libopts/FC-5/libopts.spec
>         libopts/FC-5/sources libopts/FC-6/Makefile
libopts/FC-6/branch
>         libopts/FC-6/libopts.spec libopts/FC-6/sources
>         libopts/devel/Makefile
libopts/devel/libopts.spec
>         libopts/devel/sources
> 
> Of course since there is no bugzilla component and pfj
doesn't seem to
> be around, it's hard to know what is going on... 
> 
> unless someone tells me otherwise I am going to place a
dead.package
> file in libopts/FC-5/, libopts/FC-6, libopts/devel/ and
mark it as
> Retired and request it's removal from the repos. 
> (I will do this tomorrow)
> 
> Did it really become a part of autogen on all those
branches at the
> same time?
Well, it's a bit more complicated.

libopts has always been part of autogen. Its upstream
sources are part
of autogen. However libopts also had been shipped as a
separate
standalone library package.


IIRC, at some point in FE's history, pfj had submitted
libopts and
libopts managed to make it into FE.

Later he submitted autogen, which pulled-in its own copy of
libopts and
therefore had conflicted with libopts. 

He then decided to drop the standalone libopts, and to
provide it from
inside of autogen. Also, neither autogen's upstream wanted
to change
autogen to use a separate libopts, nor did pfj want to
modify autogen to
using a standalone libopts instead of the bundled version.

=> At some point in history, we once had separate libopts
packages, now
we only have autogen and no libopts-devel nor virtual
packages inside of
autogen to "fake libopts packages" (!).

I can't find this situation to be satisfactory and actually
think this
situation is messed up. But, AFAICT, nobody but autogen
actually uses
libopts, so this isn't much of a problem.

>  Should a owners.list entry be made for it anyhow? 
Hmm, I am not sure about it. 

IMO, libopts actually is a separate package (With its own
version
numbering), but in the way libopts currently is packaged, it
only is an
internal autogen library not of much use to the public.

Ralf



-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list
libopts
user name
2006-12-22 05:54:52
On Thu, 2006-12-21 at 20:00 -0700, Kevin Fenzi wrote:
> The libopts package has no owners.list entry. 
> It's files were cvs rm'ed a while back: 
> 
> revision 1.4
> date: 2006/11/02 21:21:57;  author: pfj;  state: dead; 
lines: +0 -0
> 
> Removing package - now part of autogen
>         libopts/Makefile libopts/import.log
libopts/FC-5/Makefile
>         libopts/FC-5/branch libopts/FC-5/libopts.spec
>         libopts/FC-5/sources libopts/FC-6/Makefile
libopts/FC-6/branch
>         libopts/FC-6/libopts.spec libopts/FC-6/sources
>         libopts/devel/Makefile
libopts/devel/libopts.spec
>         libopts/devel/sources
> 
> Of course since there is no bugzilla component and pfj
doesn't seem to
> be around, it's hard to know what is going on... 
> 
> unless someone tells me otherwise I am going to place a
dead.package
> file in libopts/FC-5/, libopts/FC-6, libopts/devel/ and
mark it as
> Retired and request it's removal from the repos. 
> (I will do this tomorrow)
> 
> Did it really become a part of autogen on all those
branches at the
> same time?
Well, it's a bit more complicated.

libopts has always been part of autogen. Its upstream
sources are part
of autogen. However libopts also had been shipped as a
separate
standalone library package.


IIRC, at some point in FE's history, pfj had submitted
libopts and
libopts managed to make it into FE.

Later he submitted autogen, which pulled-in its own copy of
libopts and
therefore had conflicted with libopts. 

He then decided to drop the standalone libopts, and to
provide it from
inside of autogen. Also, neither autogen's upstream wanted
to change
autogen to use a separate libopts, nor did pfj want to
modify autogen to
using a standalone libopts instead of the bundled version.

=> At some point in history, we once had separate libopts
packages, now
we only have autogen and no libopts-devel nor virtual
packages inside of
autogen to "fake libopts packages" (!).

I can't find this situation to be satisfactory and actually
think this
situation is messed up. But, AFAICT, nobody but autogen
actually uses
libopts, so this isn't much of a problem.

>  Should a owners.list entry be made for it anyhow? 
Hmm, I am not sure about it. 

IMO, libopts actually is a separate package (With its own
version
numbering), but in the way libopts currently is packaged, it
only is an
internal autogen library not of much use to the public.

Ralf



-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list
libopts
user name
2006-12-22 22:20:35
On Fri, 22 Dec 2006 06:54:52 +0100
rc040203freenet.de (Ralf Corsepius) wrote:

> On Thu, 2006-12-21 at 20:00 -0700, Kevin Fenzi wrote:
> > The libopts package has no owners.list entry. 
> > It's files were cvs rm'ed a while back: 
> > 
> > revision 1.4
> > date: 2006/11/02 21:21:57;  author: pfj;  state:
dead;  lines: +0 -0
> > 
> > Removing package - now part of autogen
> >         libopts/Makefile libopts/import.log
libopts/FC-5/Makefile
> >         libopts/FC-5/branch
libopts/FC-5/libopts.spec
> >         libopts/FC-5/sources libopts/FC-6/Makefile
> > libopts/FC-6/branch libopts/FC-6/libopts.spec
libopts/FC-6/sources
> >         libopts/devel/Makefile
libopts/devel/libopts.spec
> >         libopts/devel/sources
> > 
> > Of course since there is no bugzilla component and
pfj doesn't seem
> > to be around, it's hard to know what is going
on... 
> > 
> > unless someone tells me otherwise I am going to
place a dead.package
> > file in libopts/FC-5/, libopts/FC-6,
libopts/devel/ and mark it as
> > Retired and request it's removal from the repos. 
> > (I will do this tomorrow)
> > 
> > Did it really become a part of autogen on all
those branches at the
> > same time?
> Well, it's a bit more complicated.
> 
> libopts has always been part of autogen. Its upstream
sources are part
> of autogen. However libopts also had been shipped as a
separate
> standalone library package.

ok

> 
> IIRC, at some point in FE's history, pfj had submitted
libopts and
> libopts managed to make it into FE.
> 
> Later he submitted autogen, which pulled-in its own
copy of libopts
> and therefore had conflicted with libopts. 
> 
> He then decided to drop the standalone libopts, and to
provide it from
> inside of autogen. Also, neither autogen's upstream
wanted to change
> autogen to use a separate libopts, nor did pfj want to
modify autogen
> to using a standalone libopts instead of the bundled
version.
> 
> => At some point in history, we once had separate
libopts packages,
> now we only have autogen and no libopts-devel nor
virtual packages
> inside of autogen to "fake libopts packages"
(!).
> 
> I can't find this situation to be satisfactory and
actually think this
> situation is messed up. But, AFAICT, nobody but autogen
actually uses
> libopts, so this isn't much of a problem.

Yeah, what a mess. ;( 

> >  Should a owners.list entry be made for it anyhow?

> Hmm, I am not sure about it. 

I guess not since it's removed. 

> 
> IMO, libopts actually is a separate package (With its
own version
> numbering), but in the way libopts currently is
packaged, it only is
> an internal autogen library not of much use to the
public.

Right. Makes sense. 

ok, later tonight I am going to add dead.package to all the
libopts
branches, and request libopts binary rpms be removed from
all the repos
(yes, we are shipping libopts right now)

> Ralf

Thanks for the excellent info Ralf. 

kevin
-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list
libopts
user name
2006-12-26 16:38:43
Hi.

On Fri, 22 Dec 2006 06:54:52 +0100, Ralf Corsepius wrote

> I can't find this situation to be satisfactory and
actually think this
> situation is messed up. But, AFAICT, nobody but autogen
actually uses
> libopts, so this isn't much of a problem.

I just found one.
tcpreplay uses it's own in-tree version of libopts (and
installs a shared
library for it, no less). I plan to submit this for FE, but
I think we need
to sort out this libopts business first.

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list
libopts
user name
2006-12-26 16:54:39
On Tue, 26 Dec 2006 17:38:43 +0100
fedoracamperquake.de (Ralf Ertzinger) wrote:

> Hi.
> 
> On Fri, 22 Dec 2006 06:54:52 +0100, Ralf Corsepius
wrote
> 
> > I can't find this situation to be satisfactory and
actually think
> > this situation is messed up. But, AFAICT, nobody
but autogen
> > actually uses libopts, so this isn't much of a
problem.
> 
> I just found one.
> tcpreplay uses it's own in-tree version of libopts (and
installs a
> shared library for it, no less). I plan to submit this
for FE, but I
> think we need to sort out this libopts business first.

Can you patch it to use 'autogen-devel' instead?

FYI, libopts has been removed now. autogen is still broken
in FC5 as
far as I know due to some odd build failures... 

If anyone has any ideas: 

http://buildsys.fedoraproject.org/build-status/j
ob.psp?uid=24510

kevin
-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list
libopts
user name
2006-12-26 17:09:16
Hi.

On Tue, 26 Dec 2006 09:54:39 -0700, Kevin Fenzi wrote

> Can you patch it to use 'autogen-devel' instead?

No need for that, it can use a system wide libopts if it
finds one
(calls autoopts-config in configure).
It does fail to find a header, then, though:
autoopts/options.h

> If anyone has any ideas: 
> 
> http://buildsys.fedoraproject.org/build-status/j
ob.psp?uid=24510

The compiler tries to link an executable (.libs/autogen),
but none of
the source files provide a symbol named "main"
(the program entry point).
Odd. Can you grep through the sources and look where that
may be found?

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list
libopts
user name
2006-12-27 00:11:37
On Tue, 26 Dec 2006 18:09:16 +0100
fedoracamperquake.de (Ralf Ertzinger) wrote:

> Hi.
> 
> On Tue, 26 Dec 2006 09:54:39 -0700, Kevin Fenzi wrote
> 
> > Can you patch it to use 'autogen-devel' instead?
> 
> No need for that, it can use a system wide libopts if
it finds one
> (calls autoopts-config in configure).
> It does fail to find a header, then, though:
autoopts/options.h

Yeah, that header isn't available in autogen-devel. 
Can you file a bug against autogen about it?

> 
> > If anyone has any ideas: 
> > 
> > http://buildsys.fedoraproject.org/build-status/j
ob.psp?uid=24510
> 
> The compiler tries to link an executable
(.libs/autogen), but none of
> the source files provide a symbol named
"main" (the program entry
> point). Odd. Can you grep through the sources and look
where that may
> be found?
> 

Yeah, there is a main() def in autogen.c... and the package
builds just
fine on fc6/devel... so it sounds like some dependency of it
behaves
differently on fc5. 

Paul (The maintainer) is looking at it now.. 

I just wanted to try and get it cleaned up in the repo. ;) 

kevin
-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list
libopts
user name
2006-12-27 15:57:15
Hi.

On Tue, 26 Dec 2006 17:11:37 -0700, Kevin Fenzi wrote

> Yeah, that header isn't available in autogen-devel. 
> Can you file a bug against autogen about it?

autogen is not in bugzilla.

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list
libopts
user name
2006-12-27 16:10:39
On Wednesday 27 December 2006 17:57, Ralf Ertzinger wrote:

> autogen is not in bugzilla.

https://bugzilla.red
hat.com/bugzilla/buglist.cgi?product=Fedora+Extras&compo
nent=autogen

-- 
fedora-extras-list mailing list
fedora-extras-listredhat.com
https://www.redhat.com/mailman/listinfo/fedora-extras-
list
[1-10] [11-13]

about | contact  Other archives ( Real Estate discussion Medical topics )