reflum, On Mon, 2010-08-16 at 22:46 +0200, Mehdi Dogguy wrote: > On 08/16/2010 09:04 PM, Patrick Matthäi wrote: > > There are also no installations in Lenny which may break, just > > because this package is quite new in Debian at all, we were just not > > 100% ready at the time where Squeeze has been frozen. :( > > > > That's what I suspected. So, basically, the sources in the archive are > not ready and you want to push as much as possible changes from > upstream's trunk. IMO, "roaraudio" is not in a releasable state and > didn't get much testing… it's only less than one month old (in the > archive) and doesn't have any reverse dependency. Maybe it's worth > considering whether we really want to include the package in a stable > release at the moment. yes we had a bad release. We figured that out and fixed things. As we do not patches in the debian package we tryed to fix everything upstream. we also got fixes from others so we fixed some more things. for example the ALSA plugin which is not build by the debian package nor the upstream package. I also said that we can offer a version which is free of those changes. However I think as they are minor the effect of a 'strange' version (with backported bugfixes) may be more confusing. If you require us to do so, we will even if we do not like that. About the usage by other packages: As you noted the package is new in debian but the project is much older (started June 2008). Some packages did not yet updated the depends, for example: #589756 (Audacious), #589760 (libao), #591636 (ices2). Those are bugs I reported because I know the upstream version has working support. There may be more reports and some devels haven't yet noticed the presense of RoarAudio in Debian for sure. Audacious for example includes very good support in 2.4, but Debian still has 2.3 (devel version) because they missed the freeze themselfs. Maybe they will do a unblock request or maybe they will do a backport or something later. Don't know. Backporting of RoarAudio would be on the list again. Also there is something I would like to call 'implecide depends' indroduced by roarify. roarify (part of libroar-compat0) is a tool to make other software use RoarAudio without them needing native support. roarify is not yet another OSS emulation but much more. It also emulates other sound systems and provides emulation for binarys to help with shell scripts and such using binarys of some sound system. It currently includes emulation for: OSS, DMX4Linux, PulseAudio (parts), EsounD, aRtsc, sndio (handled more directly by the Debian package), YIFF Sound System and RSound (not part of debian yet). Also some tools for NAS are handled. If you do a rdepends for them I'm sure you get a no that short list of tools what can use RA. The daemon it self (roard as part of the roaraudio binary package) also includes protocol emulation. Basicly the same applys for it, too. Another thing why I think the package should be in is OpenBSD's sndio API. libroarsndio (part of libroar-compat0) is developed to emulate it in a very nice way. We are in close contact with OpenBSD's upstream devels to ensure it is a good emulation. It is very helpfull to have it around for porters so they can test sndio support without needing a OpenBSD box around. (I hope it's OK to answer to the other mail as part of this as this ha snothing to do with µRoarD package) > The popcon is 2 o_O It's very simple: first of all the package is not very old. Currently most uses use a version compiled from source. You know yourself people do not upgrade as often as they should. also It's not yet in stable nor oldstable so the user basis is limited anyway. And as long as I'm not sure about if this package is inlcuded and in which state I can't realy recommend users to upgrade to the RA package and tell them later they need to upgrade again because it is removed. So what to do? Option 0: let the upstream which is (nearly) bugfix-only release in Option 1: backport bugfixes and let such a package in in this case I need to know which parts exactly you dislike so we know what to backport. Option 2: remove the package. We do dislike this most (I'm sure every package maintainer would ;) See above why we think this is bad to do. -- Philipp. (Rah of PH2)
Attachment:
signature.asc
Description: This is a digitally signed message part