I've just "released" debtree 0.6.0. The number of options has almost doubled! It's now possible to suppress Conflicts and to generate full dependency graphs (including packages that are excluded by default). Unknown packages are now marked with a light reddish shading; this could possibly help finding obsolete Conflicts. I've also added verbosity options and fixed a few minor issues. But I'm most exited by two completely new features. Build dependency graphs Besides dependency graphs for binary packages, debtree now also generates build dependency graphs for source packages. It shows both Build-Depends and Build-Depends-Indep dependencies. It also takes into account architecture conditionals (such as [!s390]). It is possible to show such conditionals in the graph, but by default it will just omit any build dependencies not relevant for the selected architecture. Here's an example for dpkg. I expected this to be a lot harder to implement, but it proved relatively straightforward. I've been quite pleased with how extensible this script has proven. Show installed packages With this feature debtree gets back to its original purpose: providing information about what packages will get installed and why. When this option is activated, debtree will shade packages that are already installed light green. So if a graph is generated for a package that is not yet installed, it is easy to see what dependencies are already satisfied and what new packages will be installed. More importantly, you can also see which dependencies could be avoided because they are only recommended or which extra suggested goodies could be installed. Here's an example for clamav. This feature can of course also be used for build dependency graphs. Want to give it a try? The script or the Debian package can be downloaded from the debtree web page. That also has usage information and more examples. P.S. I've found yet another example of an undesired dependency on gconf2.

---

Update: fixed broken link

So, now we know what the 1/4 finals will look like:

• Australia-England, Sat 6th, 13:00 UTC, Marseille
• New Zealand-France, Sat 6th, 19:00 UTC, Cardiff
• South Africa-Fiji, Sun 7th, 13:00 UTC, Marseille
• Argentina-Scotland, Sun 7th, 19:00 UTC, Paris Stade de France

France wons quite easily against Georgia (64-7). Nearly perfect match for the French team, except maybe in mauls where cleaning was not always perfect and when setting the ball back in play ("remise en jeu", I don't have the exact English technical term for this). Georgia was playing 4 days after their win against Namibia, which is pretty short for recovering. Lionel Beauxis, for his first selection in RWC, was elected MVP of this match, after a brilliant kick play. Argentina had to either win against Ireland, or lose by less than 7 points. They very brilliantly won (30-15), scoring 2 tries while Ireland scored 2 tries as well, but much less penalties. The Irish couldn't prevent Argentinians th play their game (sloooooooow but efficient). The key to win against Argentina is playing fast with rear lanes and prevent them to slow down the game, which the French failed to do in Paris. As a consequence, there is a great probability that the four major nations of southern hemisphere reach the semi finals:

• Australia had a much more complicated pool than New Zealand but they played all their matches very strongly, without much weakness. I don't really see England beating them, given the current status of their team. But, well, who knows? Noone woud have bet on England in 2003.
• New Zealand seemed invicible in pool play, but their opponents were pretty weak. The weakness of NZ seems to be their defense and maybe the lack of hard fights in pool play. France has still many weaknesses and only a perfect match can lead them to victory. We all know that the French rugby team is always playing its top rugby when not supposed to win (the NZ team probably remembers Oct 31st 1999 in Twickenham, 31-43).
• South Africa does not probably have the most brilliant game but is certainly the hardest team to beat, as they very rarely show weaknesses, contrary to Australia and New Zealand which sometimes play "the wrong side". I really don't see the Springboks fail against Fiji, though the opposition will be really interesting.
• Argentina is probably much too strong for Scotland, which I really don't see winning. Will I be proven wrong?

Rendez-vous samedi Marseille! PS: South Africa-USA will be the last pool match tonight. I'll probably skip it anyway.

Yesterday, New Zealand crushed Romania (85-8), just like they crushed all other teams they faced up to now. Of course, my only hope is that they stop crushing teams...as France is very likely to be the next one. Indeed, the only question about New Zealand is about their defensive skills as all teams they faced scored one try against them. Particularly, their wing players seem to be pretty "weak" in defense ("weak" in terms of New Zealand...:-)). I haven't seen anything of Australia-Canada (37-6). Apparently, the Australians were pretty quiet (6 tries, still!). Very unfortunately, I haven't seen THE match between Fiji and Wales (38-34). The Fiji team created an "half surprise" by qualifying for 1/4th finals. All reports I read talk about a wonderful match, with great indecision, a full commitment by both teams, and 9 tries. Sigh. I screwed programming my VCR and we were strongly disappointed this morning. Finally, Scotland managed to qualify after beating Italy 18-16. Up to the very last minute, Italy hoped to qualify but Chris Paterson scoring 6 penalties out of 6 attempted converted all occasions the Scots had to score points. I'm slightly disappointed for the Italians who played great games all along this World Cup and would have deserved to qualify and meet Argentina, France or Ireland. Today, the final 2 teams for the 1/4th finals will be determined. Argentina has great chances to finish first (they only need one bonus point) and meet Scotland. France needs to win against Georgia. Scoring the bonus point would secure the qualification for them. Ireland has little chances to qualify as they need to beat Argentina without Argentina to score a bonus point, therefore with more than 7 points difference. The most probable ticket is Argentina finishing first and France 2nd (thus meeting New Zealand).

From time to time the question comes up on Debian mailing lists of whether debian directories in upstream tarballs are harmful and what do do about them. I tend hide from such threads, since all upstream tarballs I create contain debian directories. But I realised tonight that the common wisdom from those discussions is wrong, or at least incomplete. Here's why. First, it's important the notice that this is not a problem in the rpm world. Putting an rpm spec file in an upstream tarball is considered good practice. There's no downside; if a packager needs to change how the package is put together, they can replace the spec file. And users can run rpmbuild on the tarball and get an rpm spit out. Handy. So, then, why is the equivilant practice a problem in the debian world? Three intertwined reasons:

1. The tools assume all files in debian/ are good. There's no way to make debhelper not install a debian/init script, or any similar file. Note that this problem only affects helper tools like debhelper; the core deb building tools only care about a few files that are in every debian directory. Effectively, debhelper, and (possibly) cdbs are the only tools with the problem currently.
2. The source package format doesn't support removing files from the upstream tarball. This is a pretty silly limitation that any source format better than the current one should override. If wig and pen was ever implemented, it should support some means of deleting files.
3. Package maintainers fear that they can't get upstream to make changes, or not fast enough, so worry about getting into a mess with files in an upstream debian/ that can't easily be fixed.

I feel that if any of these three problems is solved, an upstream debian directory is ok. #3 can be solved to some extent for some packages, though these solutions will always be the least satisfying. It's tempting to try to solve #1 in debhelper. I could add an --ignore switch, to make debhelper commands not act on a given file in the debian directory. (Update: done in version 5.0.57!) The best place to solve it, though, would be in the source package format. I'd be happy to see wig and pen be implemented, but would be happier to see us moving toward using a distributed revision control system as a source package format. Consider a source format that replaces .diff.gz with .git.tar.gz.

It seems that the majority of blog traffic (at least in blogs I read) is time-based. It is personal-diary entry posts, references to current events, predictions about future events, bug reports, and other things that either become obsolete or for which it’s important to know the date. For such posts it makes sense to have the date be part of the Permalink URL, and in the normal course of events such posts will tend not to be updated after release. Another type of blog traffic is posts that have ongoing reference value which will (ideally) be actively maintained to keep them current. For such posts it makes sense to have no date stamp in the Permalink - for example if I update a post about installing SE Linux on Etch once Lenny is released (a significant update) I don’t want people ignoring it when it comes up in search engines (or worse having search engines score it down) because the URL indicates that it was written some time before the release of Etch. Wordpress supports Pages as separate entities to Posts, and the names of Pages are direct links under the root of the Wordpress installation. However there is no RSS feed for Pages (AFAIK - I may have missed something) and the Wordpress themes often treat Pages differently (which may not be what you want for timeless posts). Also it is not unreasonable to have Pages and timeless posts. I’m thinking of creating a separate Wordpress installation for posts that I intend to manage for long periods of time with updates (such as documenting some aspects of software I have written). The management options for a blog server program provide significant benefits over editing HTML files. The other option would be to use a different CMS (a blog server being a sub-category of a CMS) to store such things. What I want is a clear way of presenting the data with minimal effort from me (an advantage of Wordpress for this is that I have already invested a significant amount of effort in learning how it works) and editing from remote sites (the offline blog editing tools that are just coming out is a positive point for using a blog server - particularly as I could use the same editor for blog posts and documents). Any suggestions as to how to do this? Then of course there’s the issue of how to syndicate this. For my document blog (for want of a better term) I am thinking of updating the time-stamp on a post every time I make a significant change. If you subscribe to the document feed than that would be because you want to receive new copies of the documents as they are edited. The other option would be to not change the time-stamp and then include the feed along with my regular blog feed (making two feeds be served as one is not a technical challenge). If I was to update the time stamps then I would have to write posts announcing the release of new documents. Does anyone know of someone who writes essays or howto documents in a similar manner to Rick Moen [1] or Paul Graham [2] who also does daily blog posts? I’d like to see some examples of how others have solved these problems (if there are any).

• [1] http://linuxmafia.com/


• [2] http://www.paulgraham.com/

Share This

This project that sounded like a joke when a French person announced on April 1st that he plans to review English in some texts of Debian apckages, is now well going on. Contrary to what the status page shows, this is far from being a single-person project. I receive invaluable help from a few people, with a very special mention to Justin B Rye and MJ Ray. Both of them (and a few other people, including the package maintainers) carefully review my rewrites for the considerable amount of Frenglish I introduce. One of the funniest part is reading both of them sarcastically commenting on the "dialect" we're using as we decided to go for US-style spelling and writing style (by far the most used in Debian) while MJ and Justin are definitely citizens of the UK (and very clever in GB English). But both "play the game" ('jouer le jeu' as we way in French) very constructively. I think that the improvement for packages at the end of the process (a very long one as it includes translation updates for debconf templates) is noticeable and nearly always much appreciated by package maintainers. We are indeed only limited by time. I have decided to begin with packages that use debconf (a few hundreds) and I cannot start more than 1 package per day (the initial review is very time-consuming: about 20 minutes for one package and up to 1 hour for some of them). So, of course, new contributors will be welcomed (even those speaking dialects!).

Apparently Scott James Remnant in his article on version control systems confuses arch and git. One can only speculate that his short git usage stems from the pre 1.0 days, where you had to use higher level tools (called porcelain) to happily work on git. A funny anecdote is that Scott back in his dpkg hacking year promoted arch heavily. Ubuntu^Wbzr propaganda spreads speed gains as big bonus of the last major releases. In order to be able to do that you have to start with a terrible baseline. Testing bzr on middle sized repos is no fun at all. The bzr pain inside launchpad must be beyond imagination. Nowadays it is much easier to hack on mdadm than on lvm2. The reason is that later project uses rusty cvs. With git it is really easy to contribute back. Either you mail the patches or publish your repository. git will help you along on each way. The other very big bonus of git is the big community around git. It is a community excited around building and delivering the best version control system. The git development does regular surveys on git usages and incorporates back the wishlists. The most "funny" way to use git is to run it as cvsserver. You may believe me or not i have seen git cvsserver emulation usage in the wild.

Another weekend trip to my parents' meant another successful svn-buildpackage coding session.

I worked on expanding the svnMkdirP functionality to svn-buildpackage and checked svn-upgrade. So when the testing is done (don't know when that will happen :-( ) I'll merge the work done in the svnmkdir-p branch[1] into trunk and ask for a sponsor - I don't think that will be a problem :-P.


If you want to test, don't try trunk yet[*], your should try the svnmkdir-p branch[1]. Don't forget to bump down the version.


BTW, svn-buildpackage 0.6.22 should close .....


0 eddy@bounty ~/usr/src/svn-buildpackage/svnmkdir-p $ dpkg-parsechangelog grep ^Closes sed -r -e 's#Closes:##' -e 's#[0-9] 6 #1 +#g' -e 's#\+$##' bc
13

13 bugs.

Here are the bastards:

1. 408690
2. 411666
3. 414581
4. 419996
5. 423487
6. 428225
7. 428689
8. 433404
9. 433536
10. 434932
11. 435746
12. 436133
13. 436554

[1] svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/branches/svnmkdir-p or svn://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/branches/svnmkdir-p

[*] the branch is not yet merged into trunk because it needs more thorough testing

Great match tonight between England and Tonga. I already blogged several times that England is not among my favourite teams but tonight they played very well, with a very inspired Johnny Wilkinson (except for kick goals). Their 1st try is a complete magic inspiration by him with a penalty played quickly directly in the arms of Sackey. Wow. Tonga began the match by challenging the English in physical play and some of ou neighbours probably feel like they had a big train passing over them. As long as Tonga could play wide game with their rear lines, they were close to England and even lead the score for a while after their 1st try. The physical challenge was finally won by England, which scored 4 tries and really played as they should have to win their ticket to meet Australia in 1/4th finals in Marseille. Tomorrow will feature two virtual 1/8 finals: Wales-Fiji and Scotland-Italy (in St-Etienne!). Yet again a long day for rugby fans. I bet for Wales and Italy....we'll see if I'm correct. New Zealand-Romania and Australia-Canada will be much more anecdotic as they have no real importance for qualification. I think I'll skip those two..:-)

Chris, I think the comments you show us are about as useful as this:

<cmot>   while running autogen.sh:
<cmot>   "possibly undefined macro: AC_DISABLE_STATIC"
<cmot>   what the ...
<KiBi>   That's a possibly undefined macro.
<Clint>  possibly
<cmot>   Ah, now everything becomes clear.
<peterS> which means, possibly, that macro isn't defined
<peterS> which is different from a macro being impossibly defined

With the difference that this sort of thing is funny on IRC but only moderately so in .c files. In other words, I agree with you. I've seen the same thing many times in student assignments (and probably was guilty of it writing my one assignments. The few that I did write.) The problem with reading code is mostly that you only see the details and completely miss the big picture. Comments in the code will almost never solve this, but a big-picture design document is almost never available when you want one. But when writing code, the big picture seems very clear so you don't waste time writing it, either.

There is a wide-spread myth that swap space should be twice the size of RAM. This might have provided some benefit when 16M of RAM was a lot and disks had average access times of 20ms. Now disks can have average access times less than 10ms but RAM has increased to 1G for small machines and 8G or more for large machines. Multiplying the seek performance of disks by a factor of two to five while increasing the amount of data stored by a factor of close to 1000 is obviously not going to work well for performance. A Linux machine with 16M of RAM and 32M of swap MIGHT work acceptably for some applications (although when I was running Linux machines with 16M of RAM I found that if swap use exceeded about 16M then the machine became so slow that a reboot was often needed). But a Linux machine with 8G of RAM and 16G of swap is almost certain to be unusable long before the swap space is exhausted. Therefore giving the machine less swap space and having processes be killed (or malloc() calls fail - depending on the configuration and some other factors) is probably going to be a better situation. There are factors that can alleviate the problems such as RAID controllers that implement write-back caching in hardware, but this only has a small impact on the performance requirements of paging. The 512M of cache RAM that you might find on a RAID controller won’t make that much impact on the IO requirements of 8G or 16G of swap. I often make the swap space on a Linux machine equal the size of RAM (when RAM is less than 1G) and be half the size of RAM for RAM sizes from 2G to 4G. For machines with more than 4G of RAM I will probably stick to a maximum of 2G of swap. I am not convinced that any mass storage system that I have used can handle the load from more than 2G of swap space in active use. The reason for the myths about swap space size are due to some old versions of Unix that used to allocate a page of disk space for every page of virtual memory. Therefore having swap space less than or equal to the size of RAM was impossible and having swap space less than twice the size of RAM was probably a waste of effort (see this reference [1]). However Linux has never worked this way, in Linux the virtual memory size is the size of RAM plus the size of the swap space. So while the “double the size of RAM” rule of thumb gave virtual memory twice the size of physical RAM on some older versions of Unix it gave three times the size of RAM on Linux! Also swap spaces smaller than RAM have always worked well on Linux (I once ran a Linux machine with 8M of RAM and used a floppy disk as a swap device). As far as I recall some time ago (I can’t remember how long) the Linux kernel would by default permit overcommitting of memory. For example if a program tried to malloc() 1G of memory on a machine that had 64M of RAM and 128M of swap then the system call would succeed. However if the program actually tried to use that memory then it would end up getting killed. The current policy is that /proc/sys/vm/overcommit_memory determines what happens when memory is overcommitted, the default value 0 means that the kernel will estimate how much RAM and swap is available and reject memory allocation requests that exceed that value. A value of 1 means that all memory allocation requests will succeed (you could have dozens of processes each malloc 2G of RAM on a machine with 128M of RAM and 128M of swap). A value of 2 means that a different policy will be followed, incidentally my test results don’t match the documentation for value 2. Now if you run a machine with /proc/sys/vm/overcommit_memory set to 0 then you have an incentive to use a moderately large amount of swap, safe in the knowledge that many applications will allocate memory that they don’t use, so the fact that the machine would deliver unacceptably low performance if all the swap was used might not be a problem. In this case the ideal size for swap might be the amount that is usable (based on the storage speed) plus a percentage of the RAM size to cater for programs that allocate memory and never use it. By “moderately large” I mean something significantly less than twice the size of RAM for all machines less than 7 years old. If you run a machine with /proc/sys/vm/overcommit_memory set to 1 then the requirements for swap space should decrease, but the potential for the kernel to run out of memory and kill some processes is increased (not that it’s impossible to have this happen when /proc/sys/vm/overcommit_memory is set to 0). The debian-administration.org site has an article about a package to create a swap file at boot [2] with the aim of making it always be twice the size of RAM. I believe that this is a bad idea, the amount of swap which can be used with decent performance is a small fraction of the storage size on modern systems and often less than the size of RAM. Increasing the amount of RAM will not increase the swap performance, so increasing the swap space is not going to do any good.

• [1] http://wombat.san-francisco.ca.us/faqomatic/cache/53.html


• [2] http://www.debian-administration.org/articles/550

Share This

This is more of a reminder to myself to investigate this within GPE. The basic problem is that many events recorded in applications like gpe-calendar have a direct relationship with a specific person in the contact database and can also be linked to records in the expenses database. Expenses are relatively easy if the time of the expense occurring can be related to the duration of the event but a formal link may be more useful for extra granularity.
Relating an event to a person would typically involve the event being a work placement, a project name, a customer name or the name of an organisation. It could link an event to the organiser of the event or provide a quick lookup for the location of the event to eliminate entry duplication. (Why have the address of the event in the event record if the address is already in the contacts database? Equally, why have the dates of an event in the contact record for the organiser of the event when the same organiser may well be putting on a similar event again in the future?)
I'm thinking that gpe-calendar and equivalent applications could have a field within the event record for an ID in the contact database and a preference setting for the "category" of contacts to be shown in that field, e.g. Business or Conferences. Entry of the association would simply be a drop-down box of contacts that have the appropriate category set. A similar associative field can be implemented in expenses.
This all makes creating an invoice much more reliable. The current pilot-qof method depends on the user specifying the name of the contact as the description of the event and the "vendor" or "city" of the expense.
I'm sure there are other uses for associating events with contacts and/or expenses.
No time to investigate this just yet but it is another essential step in migrating PIM into a business-friendly format, SBIM (for want of a better name).
Small business support is lacking in current free software programs, IMHO. The applications that do exist do not work together to ease the administration burden of a small business the way that the system tools work together to ease the sysadmin burden. Understandable, yes, but small businesses need this kind of support to migrate to free software. "Joined-up thinking" is the buzzword but it's basically eliminating duplication in data entry/retrieval, associating business data across disparate data sources and enabling queries and data mining to support tax calculations, business plans, time management, project management, customer data handling ... the usual small office/home office workload.
I'm inevitably concentrating on data integration in an embedded devices like iPAQs, smart phones or blueberry-type handhelds but similar requirements need to be met within the rest of the free software world too. Once I've got time to investigate this, expect some threads on debian-devel looking at how Lenny could be made more business-friendly; not seeking an "Enterprise" version but simply making it easier to administer a small business using Debian.

Since today at afternoon I'm officially working as sysadmin of my university linux servers (Debian of course) in the labs. I'm working with Skatox and our main work right now is migrate an ActiveDirectory Server to OpenLDAP and share files in a mixed-domain of Linux and Windows machines (trough Samba for Windows and NFS for Linux) with a lot of desktop limitations (given by the LDAP scheme). Then with this migration we need all the new services in Linux machines: DNS, DHCP and Firewall which are all right now on windows machines. My main question right now is how to regulate the desktop users of windows with LDAP?... I guess I'll find it out later reading more. BTW, all the machines are gonna be installed with debian (testing on desktops and stable on servers). Really, there's a lot of work to do and I cannot publish here all right now, I cannot organize my ideas, but I'll publish how's all going :-) In the middle time I will recruit more debian maintainers now that debian is gonna be used widely there :-)

NVIDIA has released new versions in both the 96xx and 71xx leagacy series. It looks like I have work to do this weekend amongst a visit from my family. The new uploads will go under the pkg-nvidia maintainership and I'm still looking for team members to look after the legacy versions.

Michael, it’s not make that supports for DESTDIR - it’s the Makefiles that do it, usually as one of the many features picked up from automake. Half the problem SCons has with this is that there’s no similarly pervasive tool set to at least set standards (even people who don’t use automake often emulate the features that people actually use) and the focus has mostly been on pure make functionality so there’s really nothing there for installation and packaging. This has resulted in projects using SCons each coming up with their own approach to these things - which can boil down to no approach at all. The situation for SCons ought to be improved fairly soon thanks to a pair Summer of Code projects from this year and last year which will together give SCons automake-style functionality - hopefully once they’re merged people will start using them when they distribute their software. In the meantime you could always ask upstream to implement DESTDIR support.

Davyd Madeley writes about vegetarianism for the environment [1] which is listed in Wikipedia as Environmental Vegetarianism [2]. He links to an article on the Huffington Post [3]. The Huffington Post article in turn links to an article on GoVeg.com about global warming [4]. Mass-produced meat is not only bad for the environment but there are also health issues related to meat consumption (due to bad practices in mass farming, combining the meat of thousands of animals into mince thus increasing the spread of bad meat, and the fact that most people in first-world countries consume significantly more meat than anyone did at any time in history). One thing that doesn’t get mentioned in these posts is the fact that farming is not required to produce meat. In fact the meat that is most healthy (due to lack of carcinogenic chemicals and free-range feeding) and has the strongest flavour (which may be a good or bad thing depending on whether you actually like the flavour of meat) is from wild animals. If you don’t like the taste of meat (which seems to be the case when people don’t like game meat) then why eat it at all? In Australia large numbers of kangaroos are killed because they eat grass more efficiently than cattle (they have evolved over tens of thousands of years to survive in Australian conditions unlike cattle). There are also a number of foreign animals that have run wild in Australia and are considered vermin, this includes rabbit, pig, buffalo, deer and camel (all of which are tasty). Even among native animals there are often times when a cull is needed. If some good seasons allow the population to increase then when there is a bad season the population has to reduce and it’s often better for them to be culled (thus providing plenty of food for the surviving animals) than for all of them to starve. There is a game meat wholesaler I’ve visited a few times that sells buffalo, rabbit, pig, camel, crocodile, possum, emu, kangaroo, and some other animals. All of the meat is from wild animals (apart from rabbit and pig none of those animals can be domesticated). I’m sure that every region has such a wholesaler that will sell to interested individuals if you know where to look (it seems impossible to buy any game meat other than kangaroo retail in Australia). Finally one thing that offends me is people who eat meat but are not prepared to kill the animal. If you aren’t prepared to kill it then you shouldn’t pay someone else to do so on your behalf! Claiming that “the animal was going to be killed anyway” is a pitiful excuse that is only suitable for children. It’s acceptable for children to eat meat without thinking about where it came from. But adults should be able to deal with the fact that eating meat means killing animals - or become vegetarian if they can’t cope with it. The book 3001 The Final Odyssey pioneered the term “corpse food” for eating meat. I believe that the term is accurate and should be used. If you can’t stomach eating corpses then there are many good vegetarian options available. There are many vegetarians in the Linux community. As these issues are getting discussed a lot recently maybe it would be good to have the vegetarians choose some good vegetarian restaurants to have Linux meetings on occasion. Davyd got a bit of negative feedback on his post, maybe if he invited a bunch of his local Linux people to have dinner at a vegetarian restaurant and they enjoyed the food then the reaction to such ideas would be more positive.

• [1] http://davyd.livejournal.com/224276.html


• [2] http://en.wikipedia.org/wiki/Environmental_vegetarianism


• [3] http://www.huffingtonpost.com/kathy-freston/vegetarian-is-the-new-pri_b_39014.html


• [4] http://goveg.com/environment-globalwarming.asp

Share This

You can read following text on SCons homepage:

SCons is an Open Source software construction tool that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache. In short, SCons is an easier, more reliable and faster way to build software.

Then they list tons of features. But why the hell it does not support DESTDIR like functionality out of the box? While googling for this I found that most projects add the same code to handle this feature that will be used by almost every Linux distribution. I think such feature should be built in into next-generation build tool. PS: If you're asking what would I use, it is simple - for Python just use distutils, they do what you need, for rest I can recommend CMake. PS2: I just need to express my disappointment after packaging pyexiv2 which uses scons.

As I have Pentax camera, I wanted to be able to extract information from maker notes it stores to EXIF. As only tool which seems to be capable of this is ExifTool and it is a Perl beast which I really don't want to use from Python, I need to add support for it to some existing library. I found two which could be used - libexif and Exiv2. Because of availability of Python bindings I choose Exiv2. The reason why I also prefer this is upcoming XMP support for which I was looking recently. The only disadvantage I can see is that libexif is more widely used by applications. Why the hell couldn't be just one library doing this? Anyway if you're interested in Pentax maker note support for Exiv2, you can find it in their bug tracker and it will hopefully appear soon in their svn ;-).