Hi,
Regarding this bug : https://bugzilla.redhat.com/204568
It does makes sense to ship the DirectFB static libraries for some users. So here are my questions : - Should they be put into the existing -devel sub-package? - Should they be put into a new separate sub-package? (-static)
I'm asking because since it's not really for "development", it would make sense to split it out in a new sub-package. Also, that way it would avoid any possible scenario where something rebuilding against DirectFB would "accidentally" link statically instead of dynamically.
Thoughts? Some existing guideline I might have missed?
Matthias
Matthias Saou wrote:
Regarding this bug : https://bugzilla.redhat.com/204568
It does makes sense to ship the DirectFB static libraries for some users. So here are my questions :
- Should they be put into the existing -devel sub-package?
- Should they be put into a new separate sub-package? (-static)
As long as the static lib doesn't change the behavior of (most) typical builds using BuildRequires: DirectFB-devel I'd say a separate package is overkill.
-- Rex
On Mon, 2006-09-25 at 06:59 -0500, Rex Dieter wrote:
Matthias Saou wrote:
Regarding this bug : https://bugzilla.redhat.com/204568
It does makes sense to ship the DirectFB static libraries for some users. So here are my questions :
- Should they be put into the existing -devel sub-package?
- Should they be put into a new separate sub-package? (-static)
As long as the static lib doesn't change the behavior of (most) typical builds using BuildRequires: DirectFB-devel I'd say a separate package is overkill.
I'd say packaging static libs into separate *-static packages should be made mandatory to * make such dependencies apparent (otherwise the next maintainer will want to drop them from *-devel and nobody will notice until somebody who can't resist linking against them will yell). * avoid bloating the distro with unnecessary libs (Almost nobody will use them). * make packages providing static libs obvious.
Besides this: Is using a userspace library such as DirectFB inside of initrd useful? I hardly can't imagine why.
Ralf
Ralf Corsepius wrote:
I'd say packaging static libs into separate *-static packages should be made mandatory to
- make such dependencies apparent (otherwise the next maintainer will
want to drop them from *-devel and nobody will notice until somebody who can't resist linking against them will yell).
- avoid bloating the distro with unnecessary libs (Almost nobody will
use them).
- make packages providing static libs obvious.
Excellent logic (that I previously totally missed, which I will blame on insufficient morning coffee). +1 to Ralf's suggestion for -static pkg.
-- Rex
On Mon, 2006-09-25 at 08:42 -0500, Rex Dieter wrote:
Ralf Corsepius wrote:
I'd say packaging static libs into separate *-static packages should be made mandatory to
- make such dependencies apparent (otherwise the next maintainer will
want to drop them from *-devel and nobody will notice until somebody who can't resist linking against them will yell).
- avoid bloating the distro with unnecessary libs (Almost nobody will
use them).
- make packages providing static libs obvious.
Excellent logic (that I previously totally missed, which I will blame on insufficient morning coffee). +1 to Ralf's suggestion for -static pkg.
+1 from me as well.
-Toshio
On Monday, 25 September 2006 at 20:24, Toshio Kuratomi wrote:
On Mon, 2006-09-25 at 08:42 -0500, Rex Dieter wrote:
Ralf Corsepius wrote:
I'd say packaging static libs into separate *-static packages should be made mandatory to
- make such dependencies apparent (otherwise the next maintainer will
want to drop them from *-devel and nobody will notice until somebody who can't resist linking against them will yell).
- avoid bloating the distro with unnecessary libs (Almost nobody will
use them).
- make packages providing static libs obvious.
Excellent logic (that I previously totally missed, which I will blame on insufficient morning coffee). +1 to Ralf's suggestion for -static pkg.
+1 from me as well.
Finally! Let me point out that PLD has been doing that for YEARS.
Regards, R.
On Mon, 2006-09-25 at 22:16 +0200, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 25 September 2006 at 20:24, Toshio Kuratomi wrote:
On Mon, 2006-09-25 at 08:42 -0500, Rex Dieter wrote:
Ralf Corsepius wrote:
I'd say packaging static libs into separate *-static packages should be made mandatory to
- make such dependencies apparent (otherwise the next maintainer will
want to drop them from *-devel and nobody will notice until somebody who can't resist linking against them will yell).
- avoid bloating the distro with unnecessary libs (Almost nobody will
use them).
- make packages providing static libs obvious.
Excellent logic (that I previously totally missed, which I will blame on insufficient morning coffee). +1 to Ralf's suggestion for -static pkg.
+1 from me as well.
Finally! Let me point out that PLD has been doing that for YEARS.
-static subpackages have always seemed to make sense to me, but it was pointed out to me originally that increasing the number of subpackages increases the size of the metadata and makes all yum operations slower.
Thoughts? Perhaps a separate -static repo?
~spot
Tom 'spot' Callaway (tcallawa@redhat.com) said:
-static subpackages have always seemed to make sense to me, but it was pointed out to me originally that increasing the number of subpackages increases the size of the metadata and makes all yum operations slower.
Thoughts? Perhaps a separate -static repo?
Depends on how many. I believe the idea is not to package *all* static libs....
Bill
On Mon, 2006-09-25 at 16:53 -0400, Bill Nottingham wrote:
Tom 'spot' Callaway (tcallawa@redhat.com) said:
-static subpackages have always seemed to make sense to me, but it was pointed out to me originally that increasing the number of subpackages increases the size of the metadata and makes all yum operations slower.
Thoughts? Perhaps a separate -static repo?
Depends on how many. I believe the idea is not to package *all* static libs....
Exactly, but isn't it apparent that we need measures to enforce this rule to shift the threshold to maintainers to be wanting to ship static libs?
So far, FE package maintainers are ignoring this rule, some are hostile against this, rpmlint doesn't warn about them, but
... RH/FC doesn't actually do better. At least on my installations the major of static libs originate from FC. How about RH behaving as a positive example and to start abandoning static libs in FC?
Ralf
On Tuesday 26 September 2006 00:54, Ralf Corsepius wrote:
... RH/FC doesn't actually do better. At least on my installations the major of static libs originate from FC. How about RH behaving as a positive example and to start abandoning static libs in FC?
Keep filing bugs. The majority of RH packages came before the guidelines, please try to continue to remember this. There is a lot of crud in the RH packages, but unless bugs are filed or effort is put into clean it up, it won't get cleaned up. Unfortunately a lot of RH packagers don't pay attention to whats going on, especially if they're mostly doing RHEL updates and just using Fedora as a inroad to RHEL. So file bugs, point out the guidelines and get the packagers attention.
On Mon, 2006-09-25 at 15:40 -0500, Tom 'spot' Callaway wrote:
On Mon, 2006-09-25 at 22:16 +0200, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 25 September 2006 at 20:24, Toshio Kuratomi wrote:
On Mon, 2006-09-25 at 08:42 -0500, Rex Dieter wrote:
Ralf Corsepius wrote:
I'd say packaging static libs into separate *-static packages should be made mandatory to
- make such dependencies apparent (otherwise the next maintainer will
want to drop them from *-devel and nobody will notice until somebody who can't resist linking against them will yell).
- avoid bloating the distro with unnecessary libs (Almost nobody will
use them).
- make packages providing static libs obvious.
Excellent logic (that I previously totally missed, which I will blame on insufficient morning coffee). +1 to Ralf's suggestion for -static pkg.
+1 from me as well.
Finally! Let me point out that PLD has been doing that for YEARS.
-static subpackages have always seemed to make sense to me, but it was pointed out to me originally that increasing the number of subpackages increases the size of the metadata and makes all yum operations slower.
Thoughts? Perhaps a separate -static repo?
To be fair - the yum operations for fc6 should be fairly dramatically sped up. Menno, Tambet and others have done some really good work to get rid of slow sections of code or repetitive pieces.
-sv
On Mon, 2006-09-25 at 17:00 -0400, seth vidal wrote:
On Mon, 2006-09-25 at 15:40 -0500, Tom 'spot' Callaway wrote:
-static subpackages have always seemed to make sense to me, but it was pointed out to me originally that increasing the number of subpackages increases the size of the metadata and makes all yum operations slower.
Thoughts? Perhaps a separate -static repo?
Ugh, separate repo is a nitemare from the point of view of installation and the build system[1]
To be fair - the yum operations for fc6 should be fairly dramatically sped up. Menno, Tambet and others have done some really good work to get rid of slow sections of code or repetitive pieces.
Sadly, we can't really speed up the download of bits. And _that_ is where this hurts us. There have been a lot of good speedups in yum; let's not go and ruin that by making people have to download and process more data
Jeremy
[1] And if it doesn't matter for these cases, then I argue they shouldn't be packaged _at all_. Because there isn't any way people are going to get to them
On Mon, 2006-09-25 at 17:23 -0400, Jeremy Katz wrote:
On Mon, 2006-09-25 at 17:00 -0400, seth vidal wrote:
On Mon, 2006-09-25 at 15:40 -0500, Tom 'spot' Callaway wrote:
-static subpackages have always seemed to make sense to me, but it was pointed out to me originally that increasing the number of subpackages increases the size of the metadata and makes all yum operations slower.
Thoughts? Perhaps a separate -static repo?
Ugh, separate repo is a nitemare from the point of view of installation and the build system[1]
To be fair - the yum operations for fc6 should be fairly dramatically sped up. Menno, Tambet and others have done some really good work to get rid of slow sections of code or repetitive pieces.
Sadly, we can't really speed up the download of bits. And _that_ is where this hurts us. There have been a lot of good speedups in yum; let's not go and ruin that by making people have to download and process more data
okay - I didn't understand where we were thinking about slowness. thanks.
-sv
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Dominik 'Rathann' Mierzejewski -
Jeremy Katz -
Jesse Keating -
Matthias Saou -
Ralf Corsepius -
Rex Dieter -
seth vidal -
Tom Callaway -
Toshio Kuratomi