> > > 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 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 libxnee-dev: --disable-gui --disable-cli --enable-lib --disable-shared --enable-static --disable-doc --disable-gnome-applet is enable lib and shared redundant? disable-doc because the docs are for bins, right? or should docs be enabled for the libs? is gnome-applet already disabled by default? Are these conflicting? Does this look totally wrong? erm...que`? > > 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. -- Josh Dukes MicroVu IT Department _______________________________________________ Xnee-devel mailing list Xnee-devel@gnu.org http://lists.gnu.org/mailman/listinfo/xnee-devel
