openSUSE packagers' take on the 3 month release cycle

[Harald Sitter]

On Tue, Jul 9, 2013 at 12:38 PM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> On Tuesday 09 July 2013 06:33:21 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.
>>
>> For build-time dependencies, particularly determining minimum version
>> requirements, I end up reading CMakeLists.txt in my favorite editor.  That's
>> not ideal either.
> what about having this information available in a standardized format, e.g. a
> dependencies.xml?

json is the new xml, so dependencies.json :P

while in theory that is a nice idea (just like having a file listing
all used licenses/copyright holders/whatever) I do not see such a file
getting maintained reliably. certainly not unless cmake dependency
tracking/detection is forcefully driven by that file. such that the
only way to pull dependencies into a kde enabled cmake project is to
use that file and prevent manual find_package calls, which would
convenientely make related macros more accessible
(macro_optional_find_package/macro_log_feature/etc.).

but since that is rather restrictive and people probably wouldn't like
it, perhaps the better way to go about this is to enhance cmake. for
example have a dummy mode where it doesn't generate any files but
simply catches all find_package calls and lists the thusly detected
dependencies. that would probably "only' catch some 99% of
dependencies; on the plus side it does not require someone to maintain
a list of dependencies manually. of course it doesn't help with
runtime dependencies but IIRC there was a discussion about how to
express their requiredness through cmake anyway (such that a user
compiling from source would know to install it and a distro doesn't
need to install it for building purposes). if we were to have runtime
dependencies expressable through cmake as well we could also list
those in the dependency list so that packagers do not forget to add
them. with frameworks in particular I suppose we need some approach to
express which module can be enhanced by another module at runtime...

I guess what I am saying is, instead of having a separate file to
track dependencies, why not simply do it in cmake, where we need to
check for them anyway (cmake could then generate a json file ;)).

HS