On Fri, 14 May 2010 15:00:58 +0800 Paul Wise wrote: > > The logic for building from existing prototype/scriptaculous packages > > is to avoid introducing duplicated code copies, which the security > > team rather despises ;) > > Hmm, that makes it more like a static library, which is bad, but not > as bad as an embedded code copy. Actually, looking the package, it > isn't quite as bad as a static library. Hmm, you could make it even > less bad by adding triggers on the prototype and scriptaculous files > and rebuilding there.
New version using triggers uploaded: http://mentors.debian.net/debian/pool/main/p/protoaculous > I'm wondering if we should encourage web developers to use this level > of insanity by packaging it in Debian? Hmmm, I guess then they'd just > dump it into their dev tree. Or not be using Debian in the first > place. Various debian packages already embed this, so its better to provide a system-wide version. Users should be free to make their own software choices (i.e. we shouldn't intentionally discourage any particular application just because there is a certain amount of dislike for it -- let the best code win). > Looking at the postinst code, actually I'm wondering if a more > generalised solution would be useful. Instead of including lots of JS > files in a page, you could define "bundles" and dpkg would then > rebuild the bundles whenever you upgrade one of the libjs-* packages > in the bundle. This could go into javascript-common to allow the speed > advantages of protoaculous with more generality. I'm not really interested in actively persuing this approach, but if it were to become a standard, I would adopt it for this package. Mike -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
