Bug 176579 - Review Request: ipsvd -- Internet protocol service daemons
Review Request: ipsvd -- Internet protocol service daemons
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Package Reviews List
Depends On:
Blocks: 176581
  Show dependency treegraph
Reported: 2005-12-26 19:10 EST by Enrico Scholz
Modified: 2007-11-30 17:11 EST (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2005-12-26 19:10:33 EST
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 13:31:17 EST
+ 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 13:37:30 EST
No, this kind of packages is designed for dietlibc. Linking with glibc does not
make sense there.
Comment 3 Jochen Schmitt 2006-02-22 14:05:45 EST
Another question, is there any hard requirement for staticly linking?
Comment 4 Enrico Scholz 2006-02-22 14:17:08 EST
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 14:31:42 EST
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 14:34:20 EST
dietlibc linked programs runs on desktops and servers too. It is not limited to
embedded systems only.
Comment 7 Enrico Scholz 2006-02-23 01:59:25 EST
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 10:18:42 EST
I have make a post on fedora-extras-list to get an opion from other contribors.
Comment 9 Jochen Schmitt 2006-02-23 12:53:13 EST
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 14:50:53 EST
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 15:39:33 EST
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 17:43:02 EST
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 12:57:41 EST
* 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 00:37:18 EDT
Perhaps this should be moved back to FE-NEW and assigned to 

Comment 15 Jason Tibbitts 2007-05-23 14:59:08 EDT
No comments in six months; it's dfinitely time for a new reviewer.
Comment 16 Patrice Dumas 2007-05-25 15:48:43 EDT
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 13:31:34 EDT
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 04:32:55 EDT
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.