On Mon, Dec 20, 2010 at 10:17 PM, Andreas Barth <[email protected]> wrote: > * Konstantinos Margaritis ([email protected]) [101220 23:04]: >> a. identify all the circural dependencies in the package tree >> (probably something ilke that is already done using some tool) >> b. Modify some packages to actually separate into 2 _source_ packages, >> a -core and a -full. The -core could be built with only minimal >> functionality and just enable the needed package to build. > > I doubt that you get enough buy-in from the maintainers to do that.
buy-in isn't being "requested", here. the problem is being stated, very very clearly: "if you do _not_ make this policy change, all chances of doing automated new ports are f****d" - and that's really the end of it. > I suggest a different way: Add a new "bootstrap mode" to the build > utilities (as per DEB_BUILD_OPTIONS='bootstrap=yes'), in which a > source package can be built even if packages marked as not relevant > for the architecture "bootstrap" are not there. Also, not all binary > packages of the source package need to be produced, but the packages > which are produced need to be technical functional (but might be > without documentation, and with an degraded user interface). (Also, > these binary packages are marked with Bootstrap: yes, to be able to > identify them.) konstantinous will be able to give a more thorough analysis of this approach, but it sounds remarkably similar to the above suggestions / ideas, with the end-result being that modifications to packages are required, and you've already made it clear that "you doubt that you get enough buy-in from the maintainers to do that". so, whichever way you look at it, you *have* to make modifications to the existing packages, and that really is the end of it. now, someone like konstantinous can do that, sure.... and then EVERYTHING he does gets thrown away, because the "maintainers don't have any buy-in"???? that's f*****g ridiculous. the alternative is: you must maintain SEPARATE parallel-packages just for automated cross-compiling, and someone must maintain those, ad nauseam??? that's equally as ridiculous and wasteful, especially when trying to keep up with debian/testing, across 30,000 packages. but... y'know what? what might _just_ work is to have a "patch" which is applied to the debian packaging, which performs a break-down as required to get cross-compiling to work across the build-depends barrier. and _guess_ what, folks - funnily enough openembedded is built precisely around this concept: to take the package (from wherever it comes) and to apply patches to it that the OE maintainer had to utilise to get the bloody thing to work. and whilst i realise that it sounds ridiculous to have "a package that is patched by debian" that is then "patched on top of that to modify the debian patches to add in cross-compiling" but if the individual debian package maintainers are, as you say "not going to buy into that" then perhaps it will be possible to embarrass them after six months of saying "err, we're patching your debian-package patches, this is ridiculous, please just bloody well add them to the package, won't you, for goodness sake". i think you'll find it's in reality nothing like as bad as you believe, and that it won't ever need to get _that_ far, not for absolutely every single maintainer, but that yes, some will get really arsey about "being told what to do". this is debian after all *sigh*... > (Basically, that adds Build-Recommends, in addition to Build-Depends.) > > As an example, take bash: > Package: bash > Binary: bash, bash-static, bash-builtins, bash-doc, bashdb > Build-Depends: autoconf, autotools-dev, patch, bison, libncurses5-dev > [!bootstrap], texinfo [!bootstrap], debhelper (>= 5), texi2html [!bootstrap], > locales, gettext, sharutils, time, xz-utils > Build-Depends-Indep: texlive-latex-base [!bootstrap], ghostscript [!bootstrap] > > This has the advantage that it doesn't require duplicating source > packages, and the changes required to an package are not that > difficult usually. ... it's somewhat intrusive, and, i think you'll find that actually there are cases where those packages _are_ required, but that you can get away with "native" versions of the same. and, also, i think you'll find that it's a bit more than just adding a [!bootstrap] flag, but that compilation options are also required (configure --without-texinfo for example - bit of a fake example but you get the idea) btw i wasn't suggesting *duplicating* source packages, i was suggesting *modifying* the source packages so that some extra packages are added *to the source package*. and you can then specifically build *only* the dependent packages required (cross-compiled) rather than "absolutely everything". i belieeeeve that this is what konstantinous is doing already, right now (k?) but he is not being asked to contribute back the modifications he's making to all these packages! (and debian as a group should be bloody well clamouring for them and supporting him!!) >> Also, It should be a fix in the policy that NO package should ever be >> allowed to have circular dependecies. Without a change in the policy >> the problem will never be fixed. > > That's not possible. There is a minimal set of packages > build-depending on themselfs - but we should try to keep that set as > minimal as possible. i think you'll find that it's, as i mentioned, sufficient to use "native" versions to do the cross-compile of those in some cases and sufficient in others to break-down into multiple packages. such that once you are "on the other side" of this circular build-depends barrier, you can then do "entirely native" just as you can right now for all ports which are already on the other side of the circular build-depends barrier. the gtk self-build-depending one was just one example, and in openembedded they use "gtk-native" - actually glade-native - to get themselves onto the other side of this self-build-depending barrier. webkit is another. you can do cross-compiling of webkit by installing native versions of flex and bison. and you'll probably find that the loop of the debootstrap stuff is the same: you'll _definitely_ need native bash, perl, awk etc. to "get started", despite the fact that the debootstrap package list itself requires bash, perl etc. l. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
