Adoptiong ecasound

[Joel Roth]

On Thu, Jan 20, 2011 at 07:59:38PM +0100, Alessandro Ghedini wrote:
> Hi all,
> I've just adopted the bug #520271 (RFA: ecasound2.2), I think it is a good
> candidate to get maintained by the Multimedia Team. 
> 
> The main problem I see is that the source package is named 'ecasound2.2' 
> even if the current version is 2.7.0 (2.7.2 if you consider upstream). 
> >From the README.Debian:
>     
>      ecasound2.2 release was a major change from 2.0 series; 
>      and that was the reason for ecasound2.2 package name; we had two
>      versions to coexist.
> 
>      For transition purposes Debian source package name still retains 
>      the ecasound2.2 name.
> 
> I think this may lead to confusion and renaming the source package to just 
> 'ecasound' would make things cleaner and clearer. AFAIK a solution would be 
> to upload the new 'ecasound' and ask for removal for the 'ecasound2.2'. 
> Is this right?

Having had a look, I agree it would be cleaner for the
source package to be named ecasound.  And for all the others
to be renamed, too.

$ grep Package: debian/control 

	Package: ecasound
	Package: libecasound2.2-dev
	Package: libecasoundc2.2-dev
	Package: libkvutils2.2-dev
	Package: python-ecasound2.2
	Package: libecasound-ruby1.8 (??)
	Package: ecasound-el

Here is the output from 'apt-cache showpkg'
on my sid distribution.

	Package: ecasound2.2
	Reverse Depends: ecasound,ecasound2.2 2.3.2-1

	Package: libecasound2.2-dev
	Reverse Depends:

	Package: libecasoundc2.2-dev
	Reverse Depends:

	Package: libkvutils2.2-dev
	Reverse Depends: libecasound2.2-dev,libkvutils2.2-dev

	Package: python-ecasound2.2
	Reverse Depends: ecasound,python-ecasound2.2 2.7.0-1.1

	Package: libecasound-ruby1.8
	Reverse Depends:

All of the packages depending on these packages appear
to be within the ecasound source package.

Based on this information, it looks like we could go
through a renaming without harming others.

If we need to be extra-careful, we could use Provides:
field to supply aliases to the old package names.

Does that seem right?

> Also, there are a lot of problems with the packaging (e.g. 24 lintian
> warnings, "ancient" packaging and a lot of mess with the generated binary
> packages) that would probably make easier to re-start packaging from
> scratch (this would be made easier by replacing 'ecasound2.2' with
> 'ecasound', see above). What do you think?

You must have done a lot since then; there are only a few
lintian warnings left.

Best,

Joel
 
> Cheers
-- 
Joel Roth