[SCM] Free Firewire Audio Drivers (ffado.org) packaging branch, master, updated. upstream/2.0rc1+svn1539-21-g54ef3a4

[Felipe Sateler]

El martes 19 de mayo, Adrian Knoth escribió:
> On Tue, May 19, 2009 at 06:23:52PM +1000, Felipe Sateler wrote:
> > I accidentally replied to Adrian privately, moving back to the list.
> > (BTW, Adrian, please don't CC me, I read the list :).
>
> Ok.
>
> > > Ah. It's all about
> > >
> > >    /usr/share/libffado/configuration
> > > That's the driver configuration file which defines all the internal
> > > settings for the different devices. It is tightly coupled to the
> > > library, and it is version-specific. With a new release of libffado,
> > > the
> >
> > There are solutions. For example, upstream could look for
> > /u/s/l/configuration- SOVERSION, or /u/s/libffado1/configuration.
>
> The latter sounds good.
>
> > > Would it help to add a "Conflicts" line, so only libffado0 or libffado1
> > > can be installed at the same time? This was my intention: get rid of
> > > libffado0, it's the old rc1, and everybody should use rc2.
> >
> > The aim of this policy is precisely to allow for both libraries to be
> > present at once. As such, the optimal solution would be to version the
> > configuration file, and distribute it with the package.
>
> Agreed. So I could remove the Replaces line...
>
> What I'm not sure about: don't remove "Replaces", but add "Conflicts".
> FFADO is work in progress, and having the old libffado0 is of no use.
> Currently, Debian's jackd doesn't use it, so nobody uses it.

No. Don't do anything of the sort.

>
> IOW, libffado0 is a mistake and should be replaced/updated by libffado1,
> the one with SONAME, with six months of bugfixes and so on.  Speaking
> from upstream's point of view, supporting an outdated rc should surely
> be avoided.

libffado0 will disappear from debian as soon as no source produces it and no 
applications provide it. Thus, as soon as the new ffado is uploaded, libffado0 
will be removed (allow for a certain delay, but it should be pretty fast). 
Remember to fix the file conflict first, though.

>
> I would be perfectly fine to manually remove libffado0 from Debian, so
> we can start from scratch with libffado1. Or, as my original intention
> was, let libffado1 conflict with libffado0, forcing all "users"
> (non-existent) to upgrade.

These tags are for dpkg, not for high-level package managers nor the users. 
Replaces means one package overwrites files from the other (ie, it is being 
replaced in the package manager sense). Conflicts means that they cannot be 
installed at the same time for some reason (file conflicts are one reason). See 
policy chapter 7 for more details.

>
> BTW: does the version bump libffado0 -> libffado1 means the package has
> to wait another month in the NEW queue?

Usually it is shorter for binary NEW than source NEW (ie, if it is a package 
rename). But yes, it has to go through NEW.


Saludos,
Felipe Sateler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20090519/970036fe/attachment.pgp>