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

Re: Some blends-dev issues



On Sat, Aug 08, 2009 at 11:15:03AM -0300, Tiago Bortoletto Vaz wrote:
> 
> Sure CDBS does much more, but the fact is that blends rules is doing a work
> that is partially made in CDBS (eg. basic debhelper stuff). I think blends
> specific rules would perfectly fits as a CDBS class, so leaving the core to
> CDBS.

I try to dive a bit deeper into this.  I used CDBS for most of my packages
especially if they are team maintained and needed a patch system.  So I
know the advantages - but I also learned that there are people who do
*not* want to use it because it hides a lot of stuff from you (which is
OK for *me* if it works, but others think differently).  I was explicitely
told by people from Debian Edu they would not consider using blends-dev
if it would use CDBS.  My main concern against it is that it is badly
documented.

Moreover the things which are done in the blends-dev common rules file
are actually not a "typical" example for CDBS anyway.  Pathces are not 
needed (native package) and the things which are done are really
simple - if you look into the recently uploaded 0.6.4 rules file which
is using a short DebHelper 7 rules file you see the following:

  1. Setting some variables (Blend name etc.)
  2. Add a script before doing generel dh_install.  The script does
     most of the Blends specific work like copying templates etc.
  3. Extending clean target which is mostly not for the build proces but
     rather needed when you build the source tarball of the blend as it
     is described at [1] (you should read this!).
  4. Provide a get-orig-source target which is also used in the
     proces to get the tarbal == before the package building process.

This does not really smell like a CDBS issue for me.

> It makes things easier for you and for blends which needs more
> flexibility in their rules.

As I told you you have full flexibility in your rules file anyway because
you are perfectly free to replace it by something else.  The basic work
is done *before* the rules file is used to obtain a valid control file
out of the tasks files.

> > What exactly do you want to use from makefile.mk?  You should know that
> 
> For now I need to scan my subdirs and perform a make $target for each one I
> find (makefile.mk does it for me).

OK.  I uderstand your issue.  I had a look into the sources of the brdesktop
packages and just found a single Makefile which has some workload:
   brdesktop-artwork: grub/Makefile
which does gzip brdesktop.xpm.  I admit that brdesktop has some additional
stuff (like artwork etc) which was not yet used by other Blends before
and when I was thinking about "blendifying" brdesktop I was wondering
whether it makes sense to this specific part of BrDesktop.  This package
is not really shipping a lot of dependencies (which is the main focus
of the blends-framework - at least currently) and it might make sense to
leave this out for the moment.  On the other hand it works with the blends
framework perfectly if you add the content of the main Makefile to the
Makefile in the brdesktop blends source.  When creating the blendified
brdesktop sources I just copied the "usual dummy Makefile" (besides
AUTHORS and COPYING files).  Just extend it and it does what you need.
Just tell me if it might not work.

> For the future I may want to use CDBS gnome rules or such.

Hmmm, I admit I tend to trust Debhelper 7 to solve all problems which
might occure in the future.  Please lets talk about this once you really
need it.
 
> Yes, I'm free to do it, and even to look for Makefiles by myself. The thing is
> the rules file from blends-dev is a nice feature which I would like to use, but
> it has actually been conflicting with other nice Debian features I also would
> be happy using :)

Well, as I explained above: use the Makefile to create the proper form
of the artwork and you should be done.
 
> I know it works for all other blends. The thing is we know brdesktop is quite
> different, but I think it's not a reason to ignore it in some blend-dev
> aspects. Brdesktop is not supposed to use a lot of blends-dev features (menus,
> user oriented stuff etc), so at least the core features should be available for
> it.

The only main difference I see in BrDesktop is the extensive artwork and I'm
keen on getting this reasonably fitting into the Blends framework.  So I
hope that we will be able to sort this out properly for the profit of all
other Blends.
 
> > Hope to get this done soon!

As I told you yesterday (right before I went to bed ;-)) this is done.

Thanks for your comments

     Andreas.
 
[1] http://blends.alioth.debian.org/blends/ap-DevelDescription.en.html#s-svn

-- 
http://fam-tille.de
Klarmachen zum Ändern!


Reply to: