On Tue, Aug 12, 2014 at 10:15:36PM +0200, Stanislav Brabec wrote:
> Karel Zak wrote:
> > On Mon, Aug 11, 2014 at 04:47:11PM +0200, Stanislav Brabec wrote:
> > > The build cycle util-linux <-> python is far the largest build cycle. In
> > > case of forthcoming SLES12 it triggers rebuild of 2921 packages!
> >
> > well, util-linux is source tarball, all depends what do you want to
> > build from the tarball. You can rebuild and use only the binding and
> > ignore everything else.
> >
> > ./configure --disable-all-programs --enable-libblkid --enable-libuuid
> > --enable-libmount --enable-pylibmount
> >
>
> This does not do what I need: It builds python bindings plus it builds
> and installs libblkid, libmount and libuuid (for the second time, as we
> already built and install them in the stage 1).
>
> I need to build util-linux with defined configure options, but do it in
> three stages with defined dependencies.
Sorry, but I don't plan to support and maintain any stages options,
all we need is to have --disable-<utilname> and then you can define
the stages in *your* build scripts (spec files).
> There is currently no way how to build python-libmount against
> system-installed instance of libmount and not the in-tree one. (It means
> that python-libmount forces to build libmount in-tree.)
Sure, nobody wants to support build against random out-of-tree libs
when we develop all together to make things consistent.
What is wrong with in-tree libs? After "make install" all the binaries
is possible to use against out-of-tree libs. Problem solved.
(Well, we can improve "make install" to not install .so libs when
only python binding is wanted.)
> I think about using $(LIBMOUNT_LIBS) instead of libmount.la (and the
> same for other in-tree libraries). LIBMOUNT_LIBS will be libmount.la
> (use in-tree libmount) during normal build, and e. g. -lmount (use
> installed libmount) during multi-stage build.
You have to also guarantee that in-tree version is exactly the same
as -lmount version...
> > Anyway, I don't understand why do you want to rebuild all recursively
> > (so result is rebuild of 2921 packages).
>
> Imagine that util-linux is updated and automatic system evaluates
> dependencies in a safe way
This is not answer to the question. I don't understand why Suse does
not use regular build roots for updates. For example for Fedora we
don't rebuild all from scratch -- just use the current system packages
to build new version (and then update the build machines). It's about
minutes to rebuild the package.
Yes, I can imagine self-hosting distro, but it's IMHO very special
situation... (new CentOS from SRPMs, Linux from scratch, etc.), but
for standard updates?
> How it looks with multi stage util-linux build:
>
> 1) util-linux stage 1 update is built
>
> 2) all high level packages are triggered to rebuild by util-linux
> changes
> systemd and python are two of triggered packages
>
> 3) all dependencies of systemd are ready => systemd is rebuilt =>
> util-linux-systemd (= util-linux stage 2) update is built
>
> 4) 2920 packages are rebuilt => python is rebuilt =>
> python-libmount (= util-linux stage 3) update is built
Sure, all this is already possible (well, there is no --disable-logger, but
we can add this option). All you need is to carefully specify --with-* and
--disable-*.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
