[OE-core] [PATCH] alsa-lib: remove non PN based -dev packages

[Richard Purdie]

On Mon, 2014-07-28 at 10:51 +0200, Koen Kooi wrote:
> Op 28 jul. 2014, om 08:49 heeft Huang, Jie (Jackie) <Jackie.Huang at windriver.com> het volgende geschreven:
> >> -----Original Message-----
> >> From: Koen Kooi [mailto:koen at dominion.thruhere.net]
> >> Sent: Monday, July 28, 2014 2:30 PM
> >> To: Huang, Jie (Jackie)
> >> Cc: OE-core; Richard Purdie
> >> Subject: Re: [OE-core] [PATCH] alsa-lib: remove non PN based -dev packages
> >> 
> >> 
> >> Op 25 jul. 2014, om 12:05 heeft jackie.huang at windriver.com het volgende geschreven:
> >> 
> >>> From: Jackie Huang <jackie.huang at windriver.com>
> >>> 
> >>> All dev related items should be packaged in the core PN-dev package
> >>> not in seperate packages.
> >> 
> >> What's the upgrade path here for image and users that have 'alsa-dev' installed? Looks like there are
> > 
> > My patch is removing 'alsa-dev' and all related files goes into '${PN}-dev' (PN=alsa-lib here), so users need to install
> > alsa-lib-dev instead of alsa-dev.
> 
> *sigh* So you have no upgrade path for situations where 'alsa-dev' is already installed or listed in a packagegroup or image. Worse, you don't even understand the problem :/
> 
> > 
> >> now 2 conflicting packages, 'alsa-dev' in the feeds and 'alsa-lib-dev' on OE, without and
> > 
> > Only 'alsa-lib-dev' now with my patch, so no conflicts.
> 
> Hahahahahaha you are really funny.

I appreciate there is a problem here and we need to fix that. There is
also an education issue, people who don't know much about it don't
appreciate the struggles of someone maintaining package feeds.

Perhaps someone could write a short section for the docs about the
issues here? In future when this kind of problem comes up, we can then
at least point at the manual section to explain it.

Currently, most docs come from the "same old people", I'm partly writing
this to remind people that others can submit them and that they can help
massively in educating people.

They don't even need to be proper patches against the docs, just write a
few paragraphs, send it Scott Rifenbark's way and he can usually do
something with it. He tends to reword things so the manual has a
consistent tone and style anyway so it needn't be word perfect either,
its the content that matters (and that is the part Scott cannot do).

Cheers,

Richard