[oe] provide libc-dev in glibc eglibc

[Phil Blundell]

On Fri, 2008-08-22 at 10:27 -0700, Khem Raj wrote:
> On (22/08/08 10:08), Phil Blundell wrote:
> > On Thu, 2008-08-21 at 18:25 -0700, Khem Raj wrote:
> > > This patch makes an alias for libc-dev which points to libc6-dev in
> > > glibc and eglibc. This makes this package have same name like uclibc.
> > > This helps in writing recipes which uses these dev packages to use
> > > just one name and do not worry about what system library is in use.
> > 
> > Is the existing libc-dev package (i.e. the one from uclibc) concrete or
> > virtual?  If the former then you should call this new alias something
> > like "virtual-libc-dev" and make uclibc's libc-dev provide it as well.
> > If libc-dev is already a pure virtual then I guess adding a direct
> > RPROVIDES for glibc is harmless enough, though it might still be a good
> > idea to use the "virtual-libc-dev" naming for clarity and to avoid any
> > future imbroglio with other libraries.
> 
> libc-dev is not virtual in uclibc, it is concrete package name. So as you suggest I used a different name virtual-libc-dev in the attached patch. 

OK, great.  This new patch looks good to me.

For what it's worth, it is almost never the right thing to have a single
package name with both virtual and concrete instantiations.  Doing this
can make it difficult or impossible to persuade ipkg/opkg to install the
concrete package that is being shadowed by the virtual one.  The only
time it is appropriate for one package to Provide: the name of another
concrete package is when one package is being replaced by or subsumed
into another one.

> > By the way, your diffs always seem to come out with MIME-type
> > "application/octet-stream" which makes them a bit tedious to view.
> > Could you send them as something like text/diff or text/plain in future?
> 
> sometimes I use the webclient and that hoses things up. I hope its
> better this time

Yes, thanks, that time it was fine.

p.