static libraries/devel subpackages

[Ralf Corsepius]

On Mon, 2005-08-22 at 18:36 +0300, Ville Skyttä wrote:
> On Mon, 2005-08-22 at 16:49 +0200, Linus Walleij wrote:
> > On Mon, 22 Aug 2005, Patrice Dumas wrote:
> >
> > > * when the package consists only in static libraries, no binaries nor dynamic
> > >  libraries what should be done? (I think that the principal package should
> > >  not distribute any file such that there is only a -devel package. It is
> > >  what libcaca does.)
> > 
> > Seems reasonable to me...
> 
> Ditto.
> 
> > Could one not just name the main package 
> > "foo-devel" then, with no "main" package whatsoever?
> 
> Just leave it at "foo", that'll result in less mess when upstream one
> day introduces stuff that doesn't belong in the -devel package.
Hmm? - IMO, the opposite is true.

IMO, the only viable approaches are:
1. Let foo.spec produce foo-devel.rpm only.
or
2. Let foo.spec produce foo.rpm only, but then let it
Provide: foo-devel = %version-%release


The rationale behind all this is:
Simple packages often start with shipping a static lib (libfoo.a) only,
and later are being extended to ship shared libs (libfoo.so,
libfoo.so.x).


At this point people will face problems if the package has started as
"foo" w/o "foo-devel"

If foo-devel is available from the earliest beginnings, packages wanting
to link against "libfoo", can 
BuildRequires: foo-devel
and don't have to be changed.

Ralf