Re: ARMv4-support in armel/squeeze?
On Mon, Dec 20, 2010 at 10:17 PM, Andreas Barth <aba@not.so.argh.org> wrote:
> * Konstantinos Margaritis (markos@genesi-usa.com) [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.
Reply to: