Boris Daix <Boris.Daix@insa-lyon.fr> writes: > Mario Lang <mlang@debian.org> writes: > > [...] > >> Version 3.5 of BRLTTY will have a speech driver module for Festival Lite. >> This module links dynamically against the quite large (6MB or so) festival >> lite library. Now, I am pondering how to go about this new module. I basically >> see two approach: > > [...] > >> Any opinions? > > I also think BRLTTY shouldn't depend on synth' -- 3.5 may live in > exp. until a good solution is found. experimental is not really necessary, splitting the fl module out of the brltty main binary package into brltty-flite seems quite a good enough soltuion to me. For those who are already glaring at me for not having packaged 3.5 for unstable in the last 2 months, I am sorry, but I think I will not make it for Sarge. A decision I made in 3.4 regarding debconf support is really hunting me. Essentially, 3.4.1 debconf support is basically broken, and I need to recode all of it from scratch, keeping backward compatibility in mind, this is a hard job to really get right. Now that we decided to split out, I also need to find a way to know if the user installed the brltty-flite package, so that I can offer the option. Given that there were a lot of changes[1] since 3.5 in upstream svn repository already, I think I'll actually skip 3.5 and aim for 3.6 or one of its pre releases. > But I wonder if the better wouldn't be to put flite stuff in, and > simply make a "Recommends" relation w/ flite plus warn user via > debconf/README. Would it be even possible (I mean: is such a > package installable, regarding shlibs and related)? No. All library relations have to be captured in package dependencies, and that is automatically taken care of. What we will need is a Suggests from brltty to brltty-flite. > On the other hand, you may also consider BRLTTY+Flite as another way of > bringing a11y, by starting a new pkg (brltty-flite) w/ full 3.5, > letting "BRLTTY only" alone behind. I guess something in some way > similar happened w/ exim / exim4, apache / apache2, and so on. This is not really equivalent. What you talk about are major upstream releases with a lot of changes so that keeping the old version is desierable. We were only pondering splitting some part of the module system into a separate binary package. > You may also ask upstream to split things for you, to let packaging > quite reasonable. That is not necessary at all. A single source package is fine, we only need to split binary package, which upstream doesnt care about at all usually. > > Anyway, BRLTTY may need a sacrifice: I think such overlaps should be > particularly clear(er) for users, even if it implies splitting 7kb > pieces. To be honest, I currently don't really know what my BRLTTY > can do after having provided me w/ Braille (it could make tea I won't > even know it...). Well, there is the documentation, you know :-). Appart from the obvious, reading upstream changelogs is very useful at times. -- CYa, Mario
Attachment:
pgpuJRjHc72wO.pgp
Description: PGP signature