Enrico Weigelt a écrit :
* Luca Barbato <[EMAIL PROTECTED]> schrieb:
Enrico Weigelt wrote:
My suggestion: make those language bindings being separate
packages. So, other packages can depend on them directly,
instead of the current, build-breaking hack.
I'm not advocating gentoo should do this step alone, but
instead join in the upstream and solve it there.
The issue is upstream related, we can workaround it using a way to
express that requirement (usedeps, checks in pkg_setup, whatever),
obviously trying to cooperate with upstream in order to get the optional
bindings build w/out the main program would make our life simpler and
probably their as well.
Partial builds are quite a problem since they are anything but reliable.
ACK. These are just hacks to work around upstream's design
problems. For me, working much embedded environments, those
hacks are not an option, since builds MUST be reliable
(the packages MUST work IMMEDIATELY after deployment, since
there is no chance for doing things like revdep-rebuild).
My vote is: declaring guidelines (or better: constraints) for
clean builds and then working directly within the upstream to
get it on the road.
Best example on how to do that is gstreamer. All the plugins come in 3
tarballs but each can be built individually. Really clean.
If the upstream really blocks it, do a
fork / maintain a patchline (like OSS-QM project does).
I'm already doing so with several packages.
I've seen you talk about that project before but I don't feel
comfortable going down that road. We want to work with upstream and let
them know what our needs are. Maintaining patches is a lot of work and
forking is even more work. Even though I'm still a relatively young
Gentoo dev (only been here for 1.5 years), I have yet to see upstream
projects reject build patches that make our lives easier.
Cheers,
Rémi
--
gentoo-dev@lists.gentoo.org mailing list
