Bundled Flash

T.C. Hollingsworth tchollingsworth at gmail.com
Sat Aug 24 02:49:56 UTC 2013


On 8/23/13, Adam Williamson <awilliam at redhat.com> 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.


More information about the devel mailing list