Bug 176579 - Review Request: ipsvd -- Internet protocol service daemons
Summary: Review Request: ipsvd -- Internet protocol service daemons
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Package Reviews List
Depends On:
Blocks: 176581
TreeView+ depends on / blocked
Reported: 2005-12-27 00:10 UTC by Enrico Scholz
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-07 08:32:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Enrico Scholz 2005-12-27 00:10:33 UTC
Spec Name or Url: http://ensc.de/fedora/ipsvd.spec
SRPM Name or Url: http://ensc.de/fedora/ipsvd-0.11.1-0.4.src.rpm
GNU Arch: ensc@ensc.de--fedora (http://ensc.de/tla/{archives}/fedora)


ipsvd is a set of internet protocol service daemons for Unix. It
currently includes a TCP/IP service daemon, and a UDP/IP service
daemon. It provides a similar functionality like D. J. Bernstein's
ucspi-tcp tools.

An internet protocol service (ipsv) daemon waits for incoming connections
on a local socket; for new connections, it conditionally runs an arbitrary
program with standard input reading from the socket, and standard output
writing to the socket (if connected), to handle the connection. Standard
error is used for logging.

Comment 1 Jochen Schmitt 2006-02-22 18:31:17 UTC
+ rpmlint of srpm fine.
+ Local build worked fine.
+ Mock build worked fine.

- rpmlint of binaries rpm complaints:

rpmlint ipsvd-0.11.1-0.4.i686.rpm
E: ipsvd statically-linked-binary /usr/bin/ipsvd-cdb
E: ipsvd statically-linked-binary /usr/bin/tcpsvd
E: ipsvd statically-linked-binary /usr/bin/udpsvd

? I think a build without the dietlibc will be a better solution.

Comment 2 Enrico Scholz 2006-02-22 18:37:30 UTC
No, this kind of packages is designed for dietlibc. Linking with glibc does not
make sense there.

Comment 3 Jochen Schmitt 2006-02-22 19:05:45 UTC
Another question, is there any hard requirement for staticly linking?

Comment 4 Enrico Scholz 2006-02-22 19:17:08 UTC
No; you have only soft benefits: static binaries are smaller, consum lesser
memory and will be executed faster.

Comment 5 Jochen Schmitt 2006-02-22 19:31:42 UTC
Sorry, from my point of view it's make no sense to use the dietlibc and link the
binaires staticly.

In an embeded environemt this may be okay, but you want inclussion your package
into Fedora Extras a distributation which runs on desktops or servers.

Comment 6 Enrico Scholz 2006-02-22 19:34:20 UTC
dietlibc linked programs runs on desktops and servers too. It is not limited to
embedded systems only.

Comment 7 Enrico Scholz 2006-02-23 06:59:25 UTC
let it me say in other words: you will gain absolutely nothing when linking the
programs dynamically against glibc. This will give only disadvantages.

This toolset is designed for bloatless systems and it should be built

Comment 8 Jochen Schmitt 2006-02-23 15:18:42 UTC
I have make a post on fedora-extras-list to get an opion from other contribors.

Comment 9 Jochen Schmitt 2006-02-23 17:53:13 UTC
Hans de Goede wrote in 


that the upstream author doesn't advice to link staticly agains the dietlibc.

So I unfortunately can't approve your package until you will have changed it in
according of rules 1.14 and 1.5 at

Comment 10 Enrico Scholz 2006-02-23 19:50:53 UTC
Upstream author mentions 'dietlibc' explicitly several times and praises the
small memory footprint. So, I think it is adviced by the upstream author.

It does not violate against rule 1.14 of the packaging guidelines which are stating

| Also applications linking against libraries should as far as possible link 
| against shared libraries not static versions.

The dynamic linking support in dietlibc exists but is very experimental so I
would not use. Linking against 'glibc' is not adviced by the upstream author and
has only disadvantages. Therefore, I can not link against shared libraries.

'rpmlint' is a great help but is far away from being perfect and gives lot of
false positives. This one, is such a false positive and can be ignored therefore.

Comment 11 Jochen Schmitt 2006-03-05 20:39:33 UTC
Sorry, I have look into the docs of ipsvd. the standard was to installing ipsvd
is the use of the normale glibc. dietlibc is descripted as a special way to
install it.

So I can't approve you. you have the thwo chances:

1.) Fix it how expected.

2.) Search another review which will except you package.

Comment 12 Enrico Scholz 2006-03-05 22:43:02 UTC
It is common and recommended practice that packagers choose the best way to
compile their package. In most cases, this is only the application of
$RPM_OPT_FLAGS (which are not set by the upstream author neither).

In this case, this includes the compilation with dietlibc which:

* makes tcpsvd runs >50% faster (read: when dietlibc version takes 100h, then
the glibc version needs 150h)

* creates >40% smaller binaries

* needs only 1/10 of the memory of a glibc version

Using 'dietlibc' does not violate any packaging guideline, so 'dietlibc' is the
best choice for ipsvd and it's my duty as packager to use 'dietlibc'.

Comment 13 Enrico Scholz 2006-03-06 17:57:41 UTC
* Mon Mar 06 2006 Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de> - 0.12.1-0
- updated to 0.12.1


Comment 14 Kevin Fenzi 2006-10-03 04:37:18 UTC
Perhaps this should be moved back to FE-NEW and assigned to 


Comment 15 Jason Tibbitts 2007-05-23 18:59:08 UTC
No comments in six months; it's dfinitely time for a new reviewer.

Comment 16 Patrice Dumas 2007-05-25 19:48:43 UTC
I'd agree to review that and I am agreeing with Enrico in that
case. However now the guideline explicitly requires to ask FESCO
to link statically, so I'll ask FESCO on behalf of Enrico.

Comment 17 Jason Tibbitts 2007-07-06 17:31:34 UTC
Looks like it wasn't reported here, but FESCo voted against allowing this
package to link statically against dietlibc.

Comment 18 Enrico Scholz 2007-07-07 08:32:55 UTC
I am tired of such non-technical, political reasoned decisions. I am revoking
this review request.

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