Re: [Xnee-devel] Packaging xnee for debian

[Henrik Sandklef]

Josh Dukes skrev:
>>>> Packages
>>>> ===========================
>>>>
>>>> I think it would be to start off with one package; 
>>>>
>>>>   cnee - containing command line verison + manual
>>> This requires parts of Xnee, no?
>> Xnee consists of
>>  cnee -command line 
>>  libxnee - the lib containing most of the functionality
>>  gnee - a gtk gui
>>  pnee - a gnome panel applet
>>  and some manuals...
>>
>>
>> cnee depends on libxnee 
>> cnee built statically (no shared libs) 
>>
>>  
>>>> and then another package;
>>>>
>>>>   xnee - cnee, gnee, pnee + all docs
>>>>   
>>>> and later on the devel package:
>>>>
>>>>   xnee-dev
>>>>
> 
> I don't know much about any of this, but perhaps it would be a good idea to 
> seperate out libxnee entirely and make it a dep of xnee. The point of the 
> library is to allow the implimentation of xnee type actions in other apps. 
> Perhaps it would even make sense to have a seperate dev tree and source 
> package, as some groups have done. Perhaps that would just be going to 
> far.... but it does make sense to me to break things into three main 
> packages, and one dev:
> 
> libxnee
> xnee -  cnee, gnee, pnee + all docs
> xnee-cli - cnee
> libxnee-dev
> 
> We at microvu are only really interested in libxnee and xnee-cli, but it 
> should'nt be that much more work to do a package of xnee full once xnee-cli 
> is done. I haven't read the debian policy documentation yet, so perhaps there 
> is another way this should be organized. 
> 
> Based on that configuration the extra config flags should be...
> 
> libxnee: --disable-gui --disable-cli --enable-lib --enable-shared 
> --disable-static --disable-doc --disable-gnome-applet

Looks correct. Doc should not be included since it is more a user doc,
then a devel doc.

> xnee: --enable-gui --enable-cli --enable-gnome-applet --disable-lib 
> --disable-shared --disable-static --disable-static-programs 
> xnee-cli: --disable-gui --enable-cli --disable-gnome-applet --disable-lib 
> --disable-shared --disable-static --disable-static-programs 

Looks correct.

> libxnee-dev: --disable-gui --disable-cli --enable-lib --disable-shared 
> --enable-static --disable-doc --disable-gnome-applet

dito

> is enable lib and shared redundant?


> disable-doc because the docs are for bins, right?

Originally to make it possible to build Xnee without dia and a bunch of
other tools. Now the docs are prebuilt so this option is somewhat obsolete.

There's a thread about "*able-doc" at bug-xnee@
  http://lists.gnu.org/archive/html/bug-xnee/2007-11/msg00000.html


> or should docs be enabled for the libs?

don't think so

> is gnome-applet already disabled by default?

It's enabled by default.

> Are these conflicting?

hope not... no, really they shouldn't be in conflict.

> Does this look totally wrong? erm...que`? 

Not at all :)

>>> How familiar are you with building debs JD? Have you ever used
>>> pbuilder? (I just started to use pbuilder myself and find it very
>>> useful.) Your goals are to build a deb for local use, but if it
>>> builds and works, I think it should be submitted to debian so
>>> everyone can use it - this would be ideal I think and in keeping
>>> with Henrik's and my philosophies about Free Software. 
> 
> We've built tons of packages internally, and use them regularly for system 
> configuration, but we've never a distribution debian package here. I'll read 
> up on pbuilder. My initial goal was just to build a deb for internal use, but 
> most of the times we do this we don't start from source. Also, for internal 
> use we only really need xnee-cli. I'm doing this partially to learn more 
> about Debian package management. My boss has OK'd this partially also to give 
> back to Linux a little bit for the all the things we've gotten. One of my 
> coworkes has also joined the list, he's the current maintainer of our 
> (ubuntu) repositories and builds/maintains most or all of our internal 
> packages at this point. 
> 
>>> As I said before, just fire off a mail if you want help or testing
>>> or what have you.
> 
> Will do... and I guess done... thanx. 
>