On Jul 17, 2006, at 12:51 PM, Eric Wilhelm wrote:
IMO, asking your dependencies to use EU::MM is at least sub-optimal.
This should not be version.pm's problem.
Right.
AFAIK, EU::MM never depended on anything that hadn't always been core.
Until now, M::B never depended on anything that wasn't core in perl
5.6. But there are lots of "optional" dependencies that aren't core
anywhere.
Which would hurt less?
1. bundling dependencies
+ simple
+ predictable
- heavy (but not that heavy)
- requires recursive build support?
- additional packaging-time task/checks required (automate)
- "cpan version" would cause two installs of version.pm (big deal?)
The "requires recursive build support" I think is true, and we could
easily get stuck there. We should probably just do a one-off (proof
of concept, sort of) specifically for version.pm bundling in M::B
itself, then tackle the larger issue of bundling arbitrary dependencies.
A couple other issues I see in general:
* When someone's already got a certain dependency installed, we
should try to preserve it whenever possible, and not install our
bundled one unless we really need to. This would eliminate the two-
installs-of-version issue above, right? Does it introduce any other
problems?
* What do we do if the install is unattended? The default for
installing bundled dependencies should probably be 'y', but it seems
too sneaky to install extra stuff unless a real human has
acknowledged that it's okay. Or?
* If we write one single .packlist, then uninstalling something
would also uninstall its dependencies, which would be really bad.
Same thing applies if someone's wrapping each dist in an RPM/Deb/
whatever on the fly. I guess we'd have to invoke 'Build/make
install' once for each bundled item, not once for the whole schmeer.
* We'll have to take on all our dependencies' dependencies too,
either by adding them to our 'requires' list, or by also bundling
them and somehow arranging the order in which things get built.
2. client-side bootstrapping
- might take more code than recursive builds
- offline builds would be difficult
- fragile (rarely used code in unpredictable situations)
+ reduce .tar.gz file by 47382 bytes
Those are ugly enough that I think we probably don't want to pursue
this, at least not yet.
-Ken
