asterisk bristuff dependency

[Tzafrir Cohen]

On Fri, May 13, 2005 at 07:34:07PM +0200, Kilian Krause wrote:
> Hi Tzafrir,
> 
> Am Mittwoch, den 11.05.2005, 23:19 +0300 schrieb Tzafrir Cohen:
> > Hi
> > 
> > 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 
> > 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.

The changelog is not good enough because you generally have to dig into
it back to find the relevant entry. And you easily tell that it is
indeed the last one.

> 
> > 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.

Today it is the first patch. There is currently just one other patch
that depends on it (astdatadir). In order to make sure we'll immediately
see which patches collide with it, I've moved it to be the last (except
astdatadir).

> 
> > 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. ;)

Not me. At least not yet. But someone may want to do that. E.g: someone
who wants to try to build the packages for HEAD.

> 
> > I would really like to see those capabilities in Sarge, because I
> > believe that the current situation creates unnecessary confusion. 
> 
> 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.

I'm currently adding them to my packages...

-- 
Tzafrir Cohen     icq#16849755  +972-50-7952406
tzafrir.cohen@xorcom.com  http://www.xorcom.com