On 8/23/13, Adam Williamson <awilliam@xxxxxxxxxx> wrote: > On Fri, 2013-08-23 at 17:12 -0700, Toshio Kuratomi wrote: >> One further thought here: >> https://fedoraproject.org/w/index.php?title=Packaging:JavaScript#Static_Inclusion_of_Libraries >> >> Taking a static library approach is also allowed. This can save packagers >> from some of the headaches you mentioned (like some things detecting the >> absolute path to libraries) but introduces the static libraries headaches >> (having to rebuild when the library package updates in order to get the >> changes that occurred there.) Not sure if we want to recommend that just >> to >> get around the directory->symlink issue but it is an option. > > Using the system copy really would be a lot cleaner, in some cases - I'd > really hope we can do it and not have to resort to static inclusion :/ +1 That exception is intended mainly for two specific classes of issues: 1. Minified JS libraries that have always bundled other libraries. For instance, jQuery has bundled sizzle.js since time immemorial, and unbundling it and requiring every webapp to add an extra <script> tag for sizzle.js would be a complete nightmare. 2. Webapps that use only parts of ginormous frameworks like dojo and build and minify their own JS file that only has the stuff they need. At least one of the maintainers of such a package would prefer to have to keep up with updates in a static copy rather than force clients to load gobs of JS that isn't used, and that makes a lot of sense. It's for case #2 that the exception got expanded to be allowed for webapp packages, but it's really not intended to just permit bundling to continue when you can just as easily unbundle. I'll look at tightening I don't consider the rpm symlink bug to be a good enough reason to invoke this exception, however annoying it is. It'll be a lot easier in the long run to just figure out the necessary spec goop to get it converted, and then the maintainers of packages dependent on tinymce will never have to worry about it again. ;-) -T.C. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
