From kde-core-devel Tue Jul 09 10:45:02 2013 From: =?ISO-8859-1?Q?=C0lex?= Fiestas Date: Tue, 09 Jul 2013 10:45:02 +0000 To: kde-core-devel Subject: Re: openSUSE packagers' take on the 3 month release cycle Message-Id: <9881320.sTAneF9d5u () monsterbad> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=137336685505927 On Tuesday 09 July 2013 06:33:21 Scott Kitterman wrote: > On Tuesday, July 09, 2013 12:05:30 PM =C0lex 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... > >=20 > > Can't we do something so you don't have to hunt this down but inste= ad just > > read a list? > >=20 > > For build time dependencies, we could do something by looking for > > find_package, and for runtime dependencies we should figure somethi= ng out. > >=20 > > Our projects are a mess when it comes to runtime dependencies, why = don't > > we > > fix that for example? >=20 > How would a run time only dependency be expressed? I've seen some pe= ople > put them in find_package, which is wrong and then we end up having to= patch > it away. We should have some kind of file specifying this in a standard way, a f= ile=20 that everybody (developers, packagers) can edit and improve. In ruby they have gem files, bundle files... I'm sure we can figure out= =20 something :p > For build-time dependencies, particularly determining minimum version= > requirements, I end up reading CMakeLists.txt in my favorite editor. = That's > not ideal either. We even have a CMakeLists parser in KDevelop, I'm sure we can use if we= really=20 need to :p What we need then is: -Be Have a strict policy on using always using find_package -Create a tool to extract the information -Include this information in the tarbals perhaps?