www.cendio.com
Bug 4804 - get rid of monolithic base package
: get rid of monolithic base package
Status: CLOSED FIXED
: ThinLinc
Build system
: trunk
: PC Unknown
: P2 Normal
: 4.4.0
Assigned To:
:
:
:
: 5256
  Show dependency treegraph
 
Reported: 2013-09-11 10:48 by
Modified: 2015-05-22 08:42 (History)
Acceptance Criteria:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2013-09-11 10:48:30
Currently we have a massive base package for the build system that contains
everything necessary to bootstrap a system. Although it contains everything
needed to easily recreate the build system from scratch, it's very annoying
changing individual components in it.

As upgrading components is the common use case, and not rebuilding it from
scratch, we should consider a redesign. We still need to make sure we can
recreate it from scratch though.
------- Comment #1 From cendio 2013-12-09 13:41:54 -------
Probably done together with bug 4357. Unsure how much the work overlaps. Time
est. based on worst case (no overlap).
------- Comment #2 From cendio 2014-11-27 10:37:08 -------
Time est. turned out to be waaaay wrong. Partly a bit too optimistic, partly
because there were a lot of cleanups that were appropriate to do at the same
time.
------- Comment #3 From cendio 2014-12-05 13:23:17 -------
I have something that can build ThinLinc now, so it is just a matter of
committing it to svn.
------- Comment #4 From cendio 2014-12-08 12:39:40 -------
Committed in r29656:29701.
------- Comment #5 From cendio 2014-12-11 11:49:18 -------
All done and nightly builds are still building successfully. Considering this
work finished.

Tester should check the documentation and attempt to rebuild things from
scratch.
------- Comment #6 From cendio 2015-04-30 12:11:46 -------
Regarding variants, to choose a variant you should set variant name to 1;

  rpmbuild ... --define "native 1"

However one can only build one variant to build and not multiple variants. It
is not clear what happens if several variants are specified. The way it is
specified is overcomplicated and it would be more natural to specify the
specific variant to build in the following way;

  rpmbuild ... --define "variant native"
------- Comment #7 From cendio 2015-05-05 13:51:43 -------
I made the mistake to perform the steps in "Automatic Rebuild" section as root
which fails when running the repo/rebuild command. It is required that you run
these steps as a user. This needs to be clarified.

Also due to the fact that the rebuild needs to be run as a user, one need to
make sure to checkout the cenbuild into the home directory, otherwise the build
within chroot will fail after a few hours. This should also be mentioned in the
documentation.

During the rebuild of the build environment the process stops and wants the
user to install native dependencies. The dependencies should be documented for
a seamless rebuild...

  flex <- cendio-build-gmp-bootstrap-win32
  zlib-devel <- cendio-build-binutils-bootstrap-i386
  texinfo <- cendio-build-bootstrap-build-i386
  bison <- cendio-build-bash.i386
------- Comment #8 From cendio 2015-05-05 14:01:28 -------
There are important information vaguely spread in different places. It should
be migrated into the top of Automatic rebuild section with information that it
affects the utils and bootstrap environment.

  "1.

Note that this package is compiled for the native system. As such,
   take care where you build it so that you can use the resulting
   package on all machines."


  "4. Build the bootstrapping environment. Like the utils package these
   packages will depend on the native environment so they should be
   built on an older system."
------- Comment #9 From cendio 2015-05-05 14:01:28 -------
There are important information vaguely spread in different places. It should
be migrated into the top of Automatic rebuild section with information that it
affects the utils and bootstrap environment.

  "1.

Note that this package is compiled for the native system. As such,
   take care where you build it so that you can use the resulting
   package on all machines."


  "4. Build the bootstrapping environment. Like the utils package these
   packages will depend on the native environment so they should be
   built on an older system."
------- Comment #10 From cendio 2015-05-06 11:43:55 -------
(In reply to comment #6)
> Regarding variants, to choose a variant you should set variant name to 1;
> 
>   rpmbuild ... --define "native 1"
> 
> However one can only build one variant to build and not multiple variants. It
> is not clear what happens if several variants are specified. The way it is
> specified is overcomplicated and it would be more natural to specify the
> specific variant to build in the following way;
> 
>   rpmbuild ... --define "variant native"

Probably, but it makes the spec files more complicated. So the current method
is preferred as you rarely build by hand.

I've elaborated a bit more on multiple variants in r30296.
------- Comment #11 From cendio 2015-05-06 11:55:20 -------
(In reply to comment #7)
> I made the mistake to perform the steps in "Automatic Rebuild" section as root
> which fails when running the repo/rebuild command. It is required that you run
> these steps as a user. This needs to be clarified.
> 

Seriously, who runs things as root? Much less builds packages as root? :)

Still, the tool will immediately tell you not to run things as root so I don't
see how you can miss it.

> Also due to the fact that the rebuild needs to be run as a user, one need to
> make sure to checkout the cenbuild into the home directory, otherwise the build
> within chroot will fail after a few hours. This should also be mentioned in the
> documentation.

It already is, in the first section on using the build environment.

> 
> During the rebuild of the build environment the process stops and wants the
> user to install native dependencies. The dependencies should be documented for
> a seamless rebuild...
> 
>   flex <- cendio-build-gmp-bootstrap-win32
>   zlib-devel <- cendio-build-binutils-bootstrap-i386
>   texinfo <- cendio-build-bootstrap-build-i386
>   bison <- cendio-build-bash.i386

Maintaining a separate list of this is bound to get out of sync, quickly making
it rather useless. I agree it is annoying though. Ideally the rebuild script
should walk the dependency list early and check for system dependencies (and
internal ones). But that's a lot more work.
------- Comment #12 From cendio 2015-05-06 12:07:16 -------
(In reply to comment #8)
> There are important information vaguely spread in different places. It should
> be migrated into the top of Automatic rebuild section with information that it
> affects the utils and bootstrap environment.
> 
>   "1.
> 
> Note that this package is compiled for the native system. As such,
>    take care where you build it so that you can use the resulting
>    package on all machines."
> 
> 
>   "4. Build the bootstrapping environment. Like the utils package these
>    packages will depend on the native environment so they should be
>    built on an older system."

Fixed in r30297.
------- Comment #13 From cendio 2015-05-06 12:25:04 -------
Review commit r30297, looks good.

Closing.
------- Comment #14 From cendio 2015-05-06 12:26:21 -------
(In reply to comment #10)
> (In reply to comment #6)
> > Regarding variants, to choose a variant you should set variant name to 1;
> > 
> >   rpmbuild ... --define "native 1"
> > 
> > However one can only build one variant to build and not multiple variants. It
> > is not clear what happens if several variants are specified. The way it is
> > specified is overcomplicated and it would be more natural to specify the
> > specific variant to build in the following way;
> > 
> >   rpmbuild ... --define "variant native"
> 
> Probably, but it makes the spec files more complicated. So the current method
> is preferred as you rarely build by hand.
> 
> I've elaborated a bit more on multiple variants in r30296.

Reviewed 30296, looks good.
------- Comment #15 From cendio 2015-05-20 13:51:38 -------
libz.so is broken for armel. Somehow the SONAME entry has gone missing,
resulting in everything getting NEEDED for the wrong .so file.
------- Comment #16 From cendio 2015-05-20 15:27:26 -------
This is caused by the horrible triplet used for armel: "arm-linux-gnueabi". It
should be grokked as CPU: arm, Vendor: <missing> OS: linux-gnueabi, not CPU:
arm, Vendor: linux, OS: gnueabi. But zlib doesn't compensate for that mess and
fails to notice that it is building for Linux.
------- Comment #17 From cendio 2015-05-20 15:45:16 -------
(In reply to comment #16)
> This is caused by the horrible triplet used for armel: "arm-linux-gnueabi". It
> should be grokked as CPU: arm, Vendor: <missing> OS: linux-gnueabi, not CPU:
> arm, Vendor: linux, OS: gnueabi. But zlib doesn't compensate for that mess and
> fails to notice that it is building for Linux.

Fixed in r30328.
------- Comment #18 From cendio 2015-05-22 08:42:03 -------
(In reply to comment #17)
> (In reply to comment #16)
> > This is caused by the horrible triplet used for armel: "arm-linux-gnueabi". It
> > should be grokked as CPU: arm, Vendor: <missing> OS: linux-gnueabi, not CPU:
> > arm, Vendor: linux, OS: gnueabi. But zlib doesn't compensate for that mess and
> > fails to notice that it is building for Linux.
> 
> Fixed in r30328.

Works as expected.