dietlibc

[Kevin Kofler]

Hi,

due to the Enrico Scholz saga, I realized that we have 4 packages in Rawhide 
which BuildRequire dietlibc:

dhcp-forwarder-0:0.10-1902.fc19.src
ip-sentinel-0:0.12-1901.fc19.src
kismet-0:0.0.2011.03.R2-1603.fc18.src
util-vserver-0:0.30.215+svn2929-1603.fc18.src

There are 2 things that strike me as broken there:

1. As far as I can tell, those packages are STATICALLY linked against 
dietlibc. Yet there is no dietlibc-static subpackage, and apparently the 
static library is in the main package (not even -devel!). There are also 
dietlibc-devel and dietlibc-header subpackages, but nothing BuildRequires or 
Requires those. The dietlibc package needs to be fixed to comply to the 
packaging guidelines (which also means that either Enrico lets go the devel 
branch or it should be forcibly removed from him!) or retired entirely (Do 
we really need a second libc in Fedora?).

2. I think those packages should not build against dietlibc at all, but just 
use the system glibc. Now that Enrico let them go, can we PLEASE get those 
packages fixed?

        Kevin Kofler

[Matthew Miller]

On Thu, Feb 28, 2013 at 11:07:13PM +0100, Kevin Kofler wrote:
>  (Do we really need a second libc in Fedora?). 
Historical footnote: I believe it was initially added to help squeeze the
boot portion of Anaconda onto floppy disks. If the things you list are
really the only things using it, I think it's time to retire it completely.

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Kevin Kofler]

Matthew Miller wrote:
>  Historical footnote: I believe it was initially added to help squeeze
> the
>  boot portion of Anaconda onto floppy disks. If the things you list are
>  really the only things using it, I think it's time to retire it
>  completely. 
The package was actually imported by Enrico in 2005.
http://pkgs.fedoraproject.org/cgit/dietlibc.git/log/?ofs=150

If what you say is correct, that would mean it was already retired and he 
resurrected it.

        Kevin Kofler

[Michael Schwendt]

On Fri, 01 Mar 2013 00:46:52 +0100, Kevin Kofler wrote:

>  Matthew Miller wrote:
>  > Historical footnote: I believe it was initially added to help squeeze the
>  > boot portion of Anaconda onto floppy disks. If the things you list are
>  > really the only things using it, I think it's time to retire it
>  > completely.
>  
>  The package was actually imported by Enrico in 2005.
>  http://pkgs.fedoraproject.org/cgit/dietlibc.git/log/?ofs=150
>  
>  If what you say is correct, that would mean it was already retired and he 
>  resurrected it. 
I must admit that I've forgotten what review procedure had been used
in 2005. Only have found this odd thread:

  RFE: dietlibc review
  http://www.redhat.com/archives/fedora-extras-list/2005-May/msg00683.html

Who remembers the details?

-- 
Fedora release 18 (Spherical Cow) - Linux 3.7.9-201.fc18.x86_64
loadavg: 0.06 0.10 0.20

[Patrice Dumas]

On Fri, Mar 01, 2013 at 11:20:24AM +0100, Michael Schwendt wrote:
>  
>  I must admit that I've forgotten what review procedure had been used
>  in 2005. Only have found this odd thread:
>  
>    RFE: dietlibc review
>    http://www.redhat.com/archives/fedora-extras-list/2005-May/msg00683.html
>  
>  Who remembers the details? 
I remember a long thread
http://www.redhat.com/archives/fedora-extras-list/2006-February/msg01720....
where Enrico showed numbers, understanding of the security issues, while
counter arguments were integration and homogeneity.  (And there was an
uninteresting discussion on whether upstream is pro or against using
dietlibc).

I have left Fedora a long time ago, but I am quite sure that the Fedora
way today is not following Enrico singular choices, even if they are
backed by evidences, but going with homogeneity and ease to maintain, 
such as to lower the bar for maintainship as much as possible, and avoid
relying on maintainer skill and knowledge of the packages.

So, I am quite convinced that rereviewing Enrico packages is certainly
the way to go to be sure that they are standard rather than innovative.

-- 
Pat

[Ralf Corsepius]

On 03/01/2013 11:20 AM, Michael Schwendt wrote:
>  On Fri, 01 Mar 2013 00:46:52 +0100, Kevin Kofler wrote:
>
> > Matthew Miller wrote:
> >> Historical footnote: I believe it was initially added to help squeeze the
> >> boot portion of Anaconda onto floppy disks. If the things you list are
> >> really the only things using it, I think it's time to retire it
> >> completely.
> >
> > The package was actually imported by Enrico in 2005.
> > http://pkgs.fedoraproject.org/cgit/dietlibc.git/log/?ofs=150
> >
> > If what you say is correct, that would mean it was already retired and he
> > resurrected it.
>
>  I must admit that I've forgotten what review procedure had been used
>  in 2005. Only have found this odd thread:
>
>     RFE: dietlibc review
>     http://www.redhat.com/archives/fedora-extras-list/2005-May/msg00683.html
>
>  Who remembers the details? 
I just found this: 
https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00060.html

I also vaguely recall some controversial reviews, where Enrico insisted 
on using dietlibc instead of glibc for "performance reasons".

Ralf

[Jon Ciesla]

On Fri, Mar 1, 2013 at 4:53 AM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:

>  On 03/01/2013 11:20 AM, Michael Schwendt wrote:
>
> > On Fri, 01 Mar 2013 00:46:52 +0100, Kevin Kofler wrote:
> >
> >  Matthew Miller wrote:
> >>
> >>> Historical footnote: I believe it was initially added to help squeeze
> >>> the
> >>> boot portion of Anaconda onto floppy disks. If the things you list are
> >>> really the only things using it, I think it's time to retire it
> >>> completely.
> >>>
> >>
> >> The package was actually imported by Enrico in 2005.
> >>
> http://pkgs.fedoraproject.org/**cgit/dietlibc.git/log/?ofs=150<http://...
> >>
> >> If what you say is correct, that would mean it was already retired and he
> >> resurrected it.
> >>
> >
> > I must admit that I've forgotten what review procedure had been used
> > in 2005. Only have found this odd thread:
> >
> >    RFE: dietlibc review
> >    http://www.redhat.com/**archives/fedora-extras-list/**
> >
> 2005-May/msg00683.html<http://www.redhat.com/archives/fedora-extras-li...
> >
> > Who remembers the details?
> >
>
>  I just found this: https://www.redhat.com/**archives/fedora-extras-list/**
>
> 2005-March/msg00060.html<https://www.redhat.com/archives/fedora-extras...
>
>  I also vaguely recall some controversial reviews, where Enrico insisted on
>  using dietlibc instead of glibc for "performance reasons".
>
>  I see no reason not to keep dietlibc around for development use, but I'd 
rather
see packages use glibc.

How should we sort out the devel ownership issue?  If we don't hear back in
X time I just take that branch too, or what?

-J


>  Ralf
>
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>
> https://admin.fedoraproject.**org/mailman/listinfo/devel<https://admin...



-- 
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love

-d. bowie

[Kevin Kofler]

Jon Ciesla wrote:
>  I see no reason not to keep dietlibc around for development use, but
> I'd
>  rather see packages use glibc. 
We agree then. But if we want to keep dietlibc, it needs to be fixed to 
comply with the packaging guidelines and best practices, i.e.:
* Shared library build needs to be enabled. I see no reason to build this 
library as static only as Enrico is doing. We tolerate this where upstream 
does not support shared builds at all, but this is not the case here.
* The main package should contain the shared library (and the documentation 
that's relevant at runtime, in particular COPYING) only. Right now it 
contains some stuff which probably belongs into -devel.
* The main package must not require -devel as it does now.
* The -devel package should not contain the static library, which should 
instead be in a -static subpackage.
* The -lib package (which is currently not built by default, it contains the 
shared library if you enable shared build) should simply be the main 
package. It doesn't make sense to have a -lib subpackage of a library.
* The -header subpackage should really be called -headers (There's more than 
one header! And it'd also be consistent with glibc.) or folded into -devel 
(though then it can't be noarch anymore).

        Kevin Kofler

[Jon Ciesla]

On Sat, Mar 2, 2013 at 9:21 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  Jon Ciesla wrote:
>  > I see no reason not to keep dietlibc around for development use, but I'd
>  > rather see packages use glibc.
>
>  We agree then. But if we want to keep dietlibc, it needs to be fixed to
>  comply with the packaging guidelines and best practices, i.e.:
>  * Shared library build needs to be enabled. I see no reason to build this
>  library as static only as Enrico is doing. We tolerate this where upstream
>  does not support shared builds at all, but this is not the case here.
>  * The main package should contain the shared library (and the documentation
>  that's relevant at runtime, in particular COPYING) only. Right now it
>  contains some stuff which probably belongs into -devel.
>  * The main package must not require -devel as it does now.
>  * The -devel package should not contain the static library, which should
>  instead be in a -static subpackage.
>  * The -lib package (which is currently not built by default, it contains
>  the
>  shared library if you enable shared build) should simply be the main
>  package. It doesn't make sense to have a -lib subpackage of a library.
>  * The -header subpackage should really be called -headers (There's more
>  than
>  one header! And it'd also be consistent with glibc.) or folded into -devel
>  (though then it can't be noarch anymore).
>
>  Excellent, can you file all of this as a BZ against dietlibc so we can 
track it,
and not rely on my imperfect memory?  I don't want to miss a
thing*.

-J

*No singing!


>          Kevin Kofler
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 



-- 
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love

-d. bowie

[Toshio Kuratomi]

On Fri, Mar 01, 2013 at 11:53:19AM +0100, Ralf Corsepius wrote:
>  On 03/01/2013 11:20 AM, Michael Schwendt wrote:
>  >On Fri, 01 Mar 2013 00:46:52 +0100, Kevin Kofler wrote:
>  >
>  >>Matthew Miller wrote:
>  >>>Historical footnote: I believe it was initially added to help squeeze the
>  >>>boot portion of Anaconda onto floppy disks. If the things you list are
>  >>>really the only things using it, I think it's time to retire it
>  >>>completely.
>  >>
>  >>The package was actually imported by Enrico in 2005.
>  >>http://pkgs.fedoraproject.org/cgit/dietlibc.git/log/?ofs=150
>  >>
>  >>If what you say is correct, that would mean it was already retired and he
>  >>resurrected it.
>  >
>  >I must admit that I've forgotten what review procedure had been used
>  >in 2005. Only have found this odd thread:
>  >
>  >   RFE: dietlibc review
>  >   http://www.redhat.com/archives/fedora-extras-list/2005-May/msg00683.html
>  >
>  >Who remembers the details?
>  
>  I just found this:
> https://www.redhat.com/archives/fedora-extras-list/2005-March/msg00060.html
>  
>  I also vaguely recall some controversial reviews, where Enrico
>  insisted on using dietlibc instead of glibc for "performance
>  reasons".
>   
I recalled this set of issues too from my previous time in fesco but I
didn't find the meeting logs with the information.  I did find this meeting
log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070531

where fesco voted to disallow static linking to dietlibc but deferred the
question of linking to dietlibc at all.

On that question, I would tend to agree with patrice's email that we've
moved towards certain core systems being too core to let people use an
alternative in Fedora (although alternatives may be provided).  Examples are
kernel (no kmods) and C compiler (IIRC, there was discussion about building
with clang that resolved in at least a decision on the list to use gcc).

There is a line somewhere as to what is "core enough" to warrant this
treatment but I think it's reasonable to think that the libc implementation
falls on the same side as the C compiler.

-Toshio

[Bill Nottingham]

Toshio Kuratomi (a.badger(a)gmail.com) said: 
>  I recalled this set of issues too from my previous time in fesco but
> I
>  didn't find the meeting logs with the information.  I did find this meeting
>  log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070531
>  
>  where fesco voted to disallow static linking to dietlibc but deferred the
>  question of linking to dietlibc at all.
>  
>  On that question, I would tend to agree with patrice's email that we've
>  moved towards certain core systems being too core to let people use an
>  alternative in Fedora (although alternatives may be provided).  Examples are
>  kernel (no kmods) and C compiler (IIRC, there was discussion about building
>  with clang that resolved in at least a decision on the list to use gcc).
>  
>  There is a line somewhere as to what is "core enough" to warrant this
>  treatment but I think it's reasonable to think that the libc implementation
>  falls on the same side as the C compiler. 
I'd agree here - note that these 4 were also packages maintained by
the former maintainer of dietlibc... it would reasonably be simple just
for the new maintainer to fix that as part of picking them up.

Bill

[Jon Ciesla]

On Fri, Mar 1, 2013 at 4:21 PM, Bill Nottingham <notting(a)redhat.com&gt; wrote:

>  Toshio Kuratomi (a.badger(a)gmail.com) said:
>  > I recalled this set of issues too from my previous time in fesco but I
>  > didn't find the meeting logs with the information.  I did find this
>  meeting
>  > log:
>  http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070531
>  >
>  > where fesco voted to disallow static linking to dietlibc but deferred the
>  > question of linking to dietlibc at all.
>  >
>  > On that question, I would tend to agree with patrice's email that we've
>  > moved towards certain core systems being too core to let people use an
>  > alternative in Fedora (although alternatives may be provided).  Examples
>  are
>  > kernel (no kmods) and C compiler (IIRC, there was discussion about
>  building
>  > with clang that resolved in at least a decision on the list to use gcc).
>  >
>  > There is a line somewhere as to what is "core enough" to warrant this
>  > treatment but I think it's reasonable to think that the libc
>  implementation
>  > falls on the same side as the C compiler.
>
>  I'd agree here - note that these 4 were also packages maintained by
>  the former maintainer of dietlibc... it would reasonably be simple just
>  for the new maintainer to fix that as part of picking them up.
>  
I've already tried it with kismet, ip-sentinel and dhcp-forwarder, with no
observable issues.  util-vserver is still orphaned.  Paul, if you'd like me
to handle dhcp-forwarder for you, let me know.

-J


>  Bill
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 



-- 
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love

-d. bowie