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