[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cdbs?? Why?



On Thursday 13 July 2006 16:28, Miriam Ruiz wrote:
>  --- Alexander Schmehl <tolimar@debian.org> escribió:
> > Hi!
> >
> > While working on the upload request queue of our request tracker, I
> > noticed some packages have been moved to cdbs recently.  May I ask you
> > why?  IIRC we discussed that topic shortly after we founded that group,
> > and agreed, that we should stick with plain debhelper (but I'm too lazy
> > to search for that thread in the archive).
>
> Yes, I remember that too. The thread I remember was here:
>
> http://lists.alioth.debian.org/pipermail/pkg-games-devel/2006-January/00014
>0.html
Sorry, i can't read the thread. Alioth is down.
>
> > Even if I fixed those FTBFS bugs (PLEASE!  Test your packages with
> > pbuilder before asking for uploads!), I won't upload a package, as long
> > as I can't reconstruct, why an arch: all packages with some data for a
> > game, needs several kdelibs and headers.
> >
> > And no, I won't read all these lines, to try to understand it:
> > $ wc -l debian/rules $(grep include debian/rules|cut -f 2 -d" ")
> >    10 debian/rules
> >   160 /usr/share/cdbs/1/rules/simple-patchsys.mk
> >    61 debian/cdbs/cmake.mk
> >   239 /usr/share/cdbs/1/rules/debhelper.mk
> >   470 total
>
> Totally understandable, I would do the same too. I think the reason for
> wanting an standard tool base is that you don't need to know every single
> tool available in Debian to know how a package is handled..
>
> Do you think we should start a new thread on that topic? I thought there
> was consensus in using debhelper and svn, and trying to avoid dpatch as far
> as I can remember, but it can be talked about, of course.
>
> I think we should try to make it easy for our sponsor DDs to understand the
> packages at a glance so that it won't be a bottleneck having to study them.


I'm the guy behind these changes.
VDrift was the first cdbs package. The job was done by the original packaged 
who did a nice work around scons and cdbs.
When i integreted it in the repository i decided to keep it.

The second package was Boson. Well i did the package some days after and i try 
to adapt VDrift cdbs script to it.

The last package is libenet. This package respect every  automake/autoconf 
standard. In this case cdbs is just the best solution since it avoid stupid 
mistake. For me libenet is a good example of a clean rules file.

I'm finishing the di-ri package with cdbs too.

The problem with boson-data and kdelibs is not a problem with cdbs but a 
problem with cmake script. I'll take a look this week end.

For me cdbs is not another useless tool for Debian. KDE team use it as a 
standard with a lot of success.
They use it because KDE sources use to respect to same build process and i 
result in a much smaller/cleaner rules file.

For the FTBFS in pbuilder. It's all my fault. I did the package when i was in 
the offline and didn't try to build it in a chroot. Some days after, when i 
had a last look on it, i forgot this point.


Regards,

		Gonéri



Reply to: