Le vendredi 28 novembre 2014 à 07:04 +0800, Thomas Goirand a écrit : > Hi, > > Web application have evolved into monsters that needs lots of > javascript. It's very common that these javascript applications are > collecting all the .js library they use, concatenate them into a single > file, and compress the result using all sorts of tools (node uglify is > one of the implementation, but that's not the only one). > > As much as possible, as good Debian citizens, we do package each and > every javascript library into a separate package. But then, if there's > an update of that JS library, the Web application package has to somehow > know about it, and redo the concatenate & compress job. Otherwise, the > web app would continue to use the old version. > > I have this issue with the OpenStack dashboard (ie: Horizon), but also > with a second web app which I'm currently packaging (OpenStack Fuel, > which is a deployment software for OpenStack). Though this could of > course be generalize to any JS app. > > It's been a long time I've been thinking about it, and I believe that > the only way to do this, would be to use triggers. Though I have never > used triggers, and I thought it was a good idea to ask my DD friends and > this list about it. Should there be one trigger per web app? How would > this work? > > Thoughts anyone? Jonas maybe, who did lots of JS packaging?
Instead of triggers, i'd rather make sure the web application package is rebuilt whenever one of its Build-Depends package is updated. That way, updates of bundled assets would be handled by the same migration process as library updates. Is it possible ? Jérémy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417438946.27821.14.ca...@melix.org
