So I’ve been extremely busy this year, I have something really exciting in the works but i don’t want to announce this until its 100% complete. But in the mean time I’ve been busy professionalizing my projects and moving them to github as the stable repos then i keep my own git repos on this server private. I’ve been getting paranoid that my server might die as i was playing around with it too much the other day.

I will announce some releases soon… Developing on a python front-end to gcc for close to 4 years i think and there have been no releases yet i think its time for one.

I need to rant about this most of my day job is packaging debian and rpm’s as well as solaris .pkg and windows .msi. I want to talk about deb vs rpm.

From my point of view of a Hadoop and Subversion packaging maintainer from WANdisco. RPM and Deb both have their advantanges and both have serious flaws. Most people tend to think of Deb’s to be magical and great. But why?

DEB

- Great tools like apt-get/aptitude

- Packages install and de-install as well as handle dependancy tree’s excessivly well.

What people don’t think about is the debian packaging work involved. And what work all goes into this. Say you have a project like gnu hello world a simple ./configure make make install type setup.

With debian the concentions are to run autoconf/automake/libtool to regenerate build system on the host system run make -C BUILD so all build work is done in another directory then the usual make install destdir=/tmp/bla so packaging and process all files properly.

So yeah this sounds fine and dandy and great. But have you actually tried to maintain a package like subversion. Go ahead…. apt-get source subversion. Take a look at debian/rules and tell me how maintainable this is, and why building commands have to be this extensive for what should be telling a .,/configure make and make install. This leads to so many problems people who are confident on how dpkg-buildpackage works and each of the hooks in the rules file. Not to mention there are 1000′s of devscripts to use and all do slight variations with little to know understanding to know whats going on.

For example whats the difference in using debuild or dpkg-buildpackage although yes i know dpkg-build-package does what it says on the tin debuild tries to sign and create source packages automatically. So there are wrappers over wrappers. But really whats going on why can we do what RPM spec’s are just put in the build commands make and make install because thats all we should care about.

So in overall i find the debian packaging system on building packages completely awful, the more i work with it/paid to work on it i am trying to look into the specificiation of what a Deb is. I would prefer to build my own set of packaing software. One of the nicest things about solaris/unix .pkg is when you take your source you manually ./configure make make install destdir=/tmp/myproject and you peek in their and basically dump it into a folder with the same layout.

Packaging isn’t complicated, but somehow people have become rock stars from maintaining a .deb.

RPM

RPM’s are funny aswell they are in themsevles archives of binaries and post scripts etc. Building them you make a funny directly structure based of a ~/.rpmmacros toplevel instruction. So you have ~/rpmbuild/{BUILD/SOURCES/RPMS….}

And you make a myproject.spec file which contains all build requirements and build instructions but it handles things much nicer so you simple tell it what to ./configure with and build with and tell it what files to care about. The only thing about rpm’s is that dependancy handling and upgrading doesn’t seem to happen aswell not to mention that yum isn’t as powerful or at least doesn’t feel as powerful as apt-get or aptitude.

PS:

I know dh_builddeb seems to simply care about the control and *.install. So wrapping a new build system into using builddeb instead of using all the system.

I’ve been scratching my head well over a few weeks why my python front-end has been basically extremely broken. But when merging bi-weekly from master gcc i tend to get the odd problem but nothing to significant. But the C++ conversion to GCC seems to be well underway which changes how i use a lot of data structures surrounding vec.h. So deciding i am just going to build my front-end off gcc 4.7 for now. And when i get to a much happier state of the code go for a merge and cleanup/conversion into C++ the code as is, changes far too frequently such that i would be much happier stabilizing things to a point when i am happy and then going to c++. Its kind of exciting and scary since all my knowledge of gcc internals is changing rapidly. Change is a good thing and gcc has been needing a cleanup and look at the nuts and bolts for quite some time along with C++ code conversion this will bring much more standardizing interfaces to coding within GCC be it a front-end/middle/back end.

I would love to see if i could modularize dot the IL i created for gccpy such that an optional ./configure flag you could opt to have support to use dot within a front-end. Generic/Gimple are fairly complicated to get used to in the beginning mostly due to silly things like Generic uses 2 different forms but you use both at the same time to represent a block within a function of conditionals and things. You create a Block which holds pointers to the DECL_CHAIN of vardecls within the block the statement list as a DECL_CHAIN again which then references a BIND_EXPR which kind of puts braces around it all then you need to setup the references for super contexts and sub contexts. Its really confusing when all you want is a nested block of code.