[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ELC access to hifive unleashed boards



Hi,

2018-03-15 18:06 GMT+01:00 Bdale Garbee <bdale@gag.com>:
> "Manuel A. Fernandez Montecelo" <manuel.montezelo@gmail.com> writes:
>
>> Even the most basic packages, like base-password, need support for the
>> whole GTK ecosystem... and documentation of many packages requires the
>> full texlive, so things are not easy.  But getting there ;)
>
> I just looked at base-passwd, and it appears that it only needs the long
> dep chain to build the docs?

The chain is like this:

base-passwd build-depends on libdebconfclient0-dev, cdebconf (the
source package that provides it) build-depends on glib, gtk and cairo.
Probably dbus and systemd are involved in that, with their own cycles
and complications.

For sure what it's involved is pango and other font libraries, one of
them is graphite2, that needs a package named python3-fonttools, and
cmake, which build-depends on Qt.

So, even without following throroughly all of the build-dependencies,
for base-password one needs a fully-fledged modern Linux distro, just
for a binary named "update-passwd", because of a front-end in GTK.

Luckily, using profiles can avoid a great deal (e.g. cmake without
Qt), but not all.

Karsten will now update cdebconf so it can use a profile to not need
GTK, so in that case it will not need much more than the compiler and
ncurses.


As another example, yesterday we patched libdebian-installer, which
needs doxygen to build, and doxygen needs JavaVM (yui-compressor) and
ruby (ruby-ronn):

  https://anonscm.debian.org/cgit/d-i/libdebian-installer.git/commit/?id=91ced1e3cca50fe2b9dffd10c8768c05f89204cb


> On previous ports, I would create forked copies of packages like this,
> whacking up the rules files and any associated configuration until I
> could build .deb files that worked adequately to continue the
> bootstrapping process.  It was annoying, but there was an adequately
> strong argument in favor of being able to use advanced tools to do
> things like create documentation for even base packages that there
> probably isn't a cleaner way?  Just set the debian/changelog entry to
> have a version string that sorts prior to the current actual version
> (use of ~ can help) and any place you install the hacked package will
> eventually clean itself up...

We're doing some of this too, like building opensp (some doc/sgml
tool) without doc for itself (otherwise needs the whole of tex).  At
some point texlive will be built and available, and "opensp" will be
built cleanly/fully.

(The packages that we build with profiles, or without but with some
kind of trick, are documented and will be probably only part of
initial buildds, but to be rebuilt later.  Otherwise yes, we're using
tricks with the versions to achieve the same effect.)

But crucially, if we add these proper annotations to the archive to
support "build profiles" (and they are kept in good shape after that),
the next architectures will have it easier, just the same way that
it's easier for us to use profiles today to avoid Java or something
else.  And the bootstrapping process becomes more clear, more
automatic, more documented, more repeatable.

Actually, back in 2014-2016 I was mostly breaking things manually, and
I got this: http://riscv.mit.edu/ , which are more than 1k packages.

Then the ABI changed dramatically in late 2016 and now nothing works,
except bash-static.  So investing time in build profiles would have
saved us quite some grief in this 2nd boostrap.

In summary: when feasible, and with profiles that make sense, is a
good tradeoff to spend some time to add them to the archive, IMO.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>


Reply to: