[Skencil-devel] Skencil build issues in modern environment

[Adam Williamson]

On Fri, 2007-04-05 at 10:24 +0200, Bernhard Reiter wrote:
> On Thursday 03 May 2007 11:10, Adam Williamson wrote:
> > I feel that the changes I do are hacks, not genuine solutions. 
> 
> Some of the changes seem just to be fine, e.g. like adding a new tcl/tk 
> version to the list or an X.org fontpath.

Oh, yeah, those two can be adopted. I think the font paths we use should
apply to all distros.

> With the path of the installation, Bernhard Herzog told me that 
> he deliberately did not place it under site-packages because there is
> not good versioning and Skencil is a full blown application and not merely
> a library. Python's distutils seem to be mainly for libraries which Skencil
> is not. Is there a comparable user application in Python in Mandriva
> that we could inspect to see where they place it?

Good idea. Here's an example - freevo:

http://sophie.zarb.org/viewrpm/0f002d883ca38b877a94ddd7a76759c7

as you can see, most stuff goes to the standard places - binaries
to /usr/bin , config stuff to /etc , static data to /usr/share - and all
the actual Python files go to /usr/lib/python2.5/site-packages/freevo .

Fedora uses the same system. So does SUSE, AFAICT. Ubuntu / Debian
appear to have a slightly customised system based around
a /usr/share/pycentral directory.

> There is the idea to be able to install more than one version of Skencil
> and call them separately. Using a subdirectory seems prudent to me.

In general distributions don't expect two versions of the same app to be
installable because it generally doesn't make sense. In the rare cases
where it does, we have systems for making it possible. This generally
involves having two packages and renaming the conflicting files (so
you'd have skencil1 and skencil2 packages,
with /usr/lib/python2.5/site-packages/skencil1
and /usr/lib/python2.5/site-packages/skencil2 , /usr/bin/skencil1
and /usr/bin/skencil2, etc). Where necessary, the Debian alternatives
system can be used to make it simple to switch between versions. This
isn't something that really needs to be made possible upstream IMHO,
unless for some reason you think it's critical.

> > From what I've seen, 
> > the build system Skencil uses is rather old, and I suspect if 
> > you look at what is available in python 2.5 or what is used by other
> > modern python apps, it would include much more robust fixes for the same
> > issues.
> 
> We have to inquire about the lib64 things 
> and see what more modern distutils would actually help with.

OK, cool :) You couldn't use my hacks, obviously, as they will only work
within an RPM build where the libdir macro is available. But I'm sure
it's something that you could get just by updating to a more modern
Python build system.

> > I feel at least the first workaround indicates a problem with Skencil:
> > the Skencil build process is doing something wrong to actually write the
> > buildroot directories into the generated files. Generally speaking, with 
> > a good build system, this kind of workaround in a spec file is not
> > necessary. I'm sorry I'm not a hacker and so can't tell you what the
> > build process is doing wrong :(
> 
> Yes, this looks like a defect in the build process somewhere. 
> Thanks a lot for your hints and opinions, this is quite useful and
> hey it makes you a hacker even if you are not a hard-core coder! ;)

Thanks :) As I mentioned, this workaround is not mine, it was in the
package when I came to it. Unfortunately it's not commented so I can't
tell who the original author was, otherwise I'd find them and ask if
they know what's wrong with the build process :)
-- 
adamw