asterisk bristuff dependency

[Kilian Krause]

--=-dfu4Lp73vYBoD/SkRF0W
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi Tzafrir,

Am Mittwoch, den 11.05.2005, 23:19 +0300 schrieb Tzafrir Cohen:
> Hi
>=20
> I'm working on refreshing the bristuff patches into our packages.
> While doing this I'm trying to figure out the best way to fit them into
> our package. I'm trying 0.2.0-RC8d

great. Very welcome ;)

> Currently the version number of the bristuff patch is not clearly=20
> stated anywhere in the package metadata. Maybe this is why we were using
> such an old version of it for so long: it just wasn't visible.

it's not that old for what i've seen. At least until the RC8 - without
any letter - the diff was minimal or you bet i'd have filed a bug with
wishlist "new bristuff". My websec has the all-seeing-eye over all my
upstream sources and i do at least look through the ChangeLog when i see
a diff. Is there any reason you claim RC8d is *required* now?

Btw. when launching asterisk CLI you have the version number right at
hand. Nevertheless i'm all ears where in the "metadata" you'd like it to
be except from the debian/changelog ;)

> I could not find a better place to put that information, so I currently
> put it in each package's description. I don't think that the version
> field is the right place for that, and the release field seems to be
> quite limited.

we can of course do some "1:1.0.7-2+bsRC8" or something, but i doubt
anybody but us would be able to read that. And still it's in the
changelog and online version info of asterisk.

> I also want to make it as easy as possible to remove those patches are
> very intrusive. If they introduce fixes they surely introduce some bugs
> in the new code of the fixes, and those bugs are bound to bother some
> people. Not to mention the fact that bristuff does not exist for HEAD.

I seem to have missed we do support HEAD. Disabling the patches is only
a matter of editing debian/patches/00list for libpri, zaptel and
asterisk. Plus rebuilding, plus installing those and plus tagging them
"hold" for obvious reasons.

> So I would like to clearly mark the packages as different. I decided to
> have the provide an extra capability: libpri1 provides
> libpri1-bristuffed and libpri-dev provides libpri-bristuffed-dev . I
> currently only got as far as libpri, but I figure other packages will
> build-required the bristuffed-dev and require the -bristuffed libs.

that will become a major headache to built all the packs twice. If
you're willing to do a double packaging patch, i'll be happy to make it
fit, but right now I'll for sure not write it. However I see your point
and I feel it's a valid critizism we face in the field and your approach
would indeed fix this very nicely and cleanly. ;)

> I would really like to see those capabilities in Sarge, because I
> believe that the current situation creates unnecessary confusion.=20

Partly agreed, but getting this into Sarge is most probably nowhere near
realistic. The changes are fundamental and you might just consider the
new asterisk-app-fax issue.

--=20
Best regards,
 Kilian

--=-dfu4Lp73vYBoD/SkRF0W
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBChOUPvdkzt4X+wX8RAnRfAJ92b4njCzihlop5EUhSIxe7G10cAgCfRR0N
HBqv4CvQedUelaRVvNLIaB0=
=kdqm
-----END PGP SIGNATURE-----

--=-dfu4Lp73vYBoD/SkRF0W--