Hi all,
I was advised to share a project of mine with this mailing list, as people may 
find it helpful and have things to add. I am normally opposed to having my 
private email be available to the public, but I will make an exception in this 
case. I have been working on a CDE package for Debian as of recent, and would 
like to share some of my progress. Good news is, the package builds and with 
some proper tweaking works without any major issues. The bad news is, is that 
Debian's standards for packages immediately disqualifies the package due to a 
number of issues. Luckily that number is small, but there are some sizable 
issues. The issues are as follows:

- Non standard directory creation - this includes the directories C, ja, and 
infolib on root and the existence of /usr/dt. The contents of C and ja seem to 
be the exact same, so perhaps their functionality can be merged and moved 
elsewhere, infolib doesn't seem to have much of anything in it, and I don't 
really see the purpose of it's existence. /usr/dt is the biggest problem facing 
a CDE package. The short term simple solution would be to find a different 
place to store it in a standard directory, but the goal would be to specify a 
directory via the build mechanism, however CDE ignores DESTDIR, so this could 
be difficult.
- Missing source code (supposedly) - Lintian, when checking for errors in the 
built package, finds binaries for dtbuilder and instant, and says that they are 
missing source code due to them being in binary format, but both of them have 
code. I suspect that for dtbuilder, this is an issue relating to a case 
mismatch in the makefile, it builds "dtbuilder" but cleans "Dtbuilder", and 
thus when I run clean, it will not clean. As for instant, I still have to look 
into it a bit further as it makes and cleans just fine.
- Binaries defining rpath - dsdm, dtdspmsg, dtsrclean, dtsrcreate, dtsrdbrec, 
dtsrdelete, dtsrhan, dtsrindex, dtsrkdump, dtsrload, huffcode, imake and nsgmls 
all define rpath to /usr/lib, debian explains why this is a problems here: 

- Package has unnecessary activation of ldconfig trigger, this might be an 
issue with CDE or a bug in lintian, I still need to look into it more.
- libssl - Package makes use of libssl, I need to find out to what degree, and 
if it is actually a dependency like the wiki says, I will ignore it for now as 
trying to get the correct dependency on my system is for some reason a 
challenge. If libssl is truly needed for the project, the license must include 
a linking exception clause as displayed here: 

Some issues that are not blocking a release but are frowned upon by Debian:

- Being a git release, since 2.2.4 isn't going to be seeing any of the issues 
above patched, and also a few people tested 2.2.4 without libxp and it fails to 
build, whereas the new build works. I decided to use the git release, however 
this is frowned upon due to one of Debian's goals is being stable.
- Setting rpcbind to insecure, maybe be fixable with some tweaks in libtirpc.
- CVEs, although I know that with the first one mentioned, it was patched by 
ibm and some other unix companies, does anyone have connections with them and 
would be willing to ask them for the patch? They may even have one for the 
second CVE as well.

The main issues being worked on are compiler and coverity warnings, which means 
that these issues are being put on hold until further notice unless me or 
someone else decides to pick them up, so please le me know if you are 

Thank you for your time,
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
cdesktopenv-devel mailing list

Reply via email to