Mailinglist Archive: opensuse-buildservice (266 mails)

< Previous Next >
[opensuse-buildservice] Re: [opensuse-packaging] OBS 101: How to threat packages with multiple spec files
  • From: todd rme <toddrme2178@xxxxxxxxx>
  • Date: Thu, 10 Jan 2013 11:23:13 -0500
  • Message-id: <CADb7s=sgzfRq+-G5=jUbHE0Q_+fMhd8RcR0QCxEaykKZgdEPeQ@mail.gmail.com>
On Jan 10, 2013 1:42 PM, "Marcus Hüwe" <suse-tux@xxxxxx> wrote:

Hi,

On 2013-01-10 10:22:52 +0100, Sascha Peilicke wrote:

<SNIP>

Even though you end up with four OBS packages, you only have to modify /
fix "python-nose" due to the links. This is much better than using
copypac (as I've seen recently). Of course you should only split up into
several spec files if there's a very good reason for the extra work.
Here are some:

- To avoid build cycles
- To off-load looong-running parts of a package build, like:
+ Running a testsuite ($PACKAGE-testsuite.spec)
+ Building documentation ($PACKAGE-doc.spec)

Hmm I don't think it's a good idea to move the run of a testsuite
or the doc building to different spec files because it might decrease
the "quality" of a package. For instance:
- the package is pushed to the repo even if the testsuite fails
- the package and package-doc might be inconsistent (if the package is
pushed to the repo and the doc building fails)

IMHO it's probably better to comment out the long running parts (or
define some macros for them) when doing local builds.

There is another common reason for splitting packages, especially doc
packages. If a package is used as a dependency for a large number of
other packages, splitting the doc package allows the build of the
other packages to start much earlier since they don't have to wait for
the documentation to finish.

This is especially true when the documentation is dynamically
generated API documentation and thus takes a long time to build.

This is the case with this example, where nose is used as a
post-install check for a massive I number of python packages, and many
of those that don't use it depend on ones that do. Further, as with
most python packages the API documentation is dynamically generated.

Trying to build the documentation would be a bottleneck for almost the
entire repo, as well as a big chunk of factory.

There are several other widely-used python packages that are built the
same way for the same reason. And this is by no means unique to
python, I see it in other repos where critical components are in the
same tarball as not-so-critical ones.
--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >