openSUSE packagers' take on the 3 month release cycle

Alexander Neundorf neundorf at kde.org
Tue Jul 9 21:07:30 BST 2013


On Tuesday 09 July 2013, Scott Kitterman wrote:
> On Tuesday, July 09, 2013 12:05:30 PM Àlex Fiestas wrote:
> > On Monday 08 July 2013 22:01:29 Andrea Scarpino wrote:
> > > We don't just run a sed rule on each spec (pkgbuild, in my case) file.
> > > We check for new dependencies (resp. dependencies not needed anymore),
> > > new modules (resp. modules not part of the SC anymore), build failure,
> > > etc...
> > 
> > Can't we do something so you don't have to hunt this down but instead
> > just read a list?
> > 
> > For build time dependencies, we could do something by looking for
> > find_package, and for runtime dependencies we should figure something
> > out.
> > 
> > Our projects are a mess when it comes to runtime dependencies, why don't
> > we fix that for example?
> 
> How would a run time only dependency be expressed?  I've seen some people
> put them in find_package, which is wrong and then we end up having to
> patch it away.

This depends how it is used with find_package().

If the package is searched optionally (i.e. not REQUIRED) and even marked as 
RUNTIME, then it is a good thing, users/developers requested this capability 
and you don't have to patch it out.

This is done e.g. in solid:

 find_package(MediaPlayerInfo)

 set_package_properties(MediaPlayerInfo PROPERTIES
  DESCRIPTION "Enables identification and querying of portable media players"
  PURPOSE "Runtime-only dependency of the udev solid backend. Support for m-p-
i is included even if not found during build"
   URL "http://www.freedesktop.org/wiki/Software/media-player-info"
   TYPE RUNTIME
  )



Done this way, at the end of the cmake run you get a summary which shows that 
the package "MediaPlayerInfo" is needed, but not for building, but only at 
runtime.

Alex




More information about the kde-core-devel mailing list