|
|
Magnus Therning wrote:
I agree with you on that. However, my impression has always been that
the Python people _don't_ think that and therefore distutils is
perfectly acceptable from a Python point of view. Packaging the SW for
Debian requires moving quite a few files around in the install step.
I couple of conversations in the Python mailing list about this and I
think the impression you have is more a defensive reaction than anything
else. They have a fair amount of investment in the current way of doing
things and as we all know, psychological investments makes it difficult
to change position. I have learned this from both side in my advocacy
of hybrid sender-pays as an anti-spam technique and a way of fixing the
damage of blacklists. I also think the installation process has impeded
the uptake. It still takes me a couple of hours to do an install and I
know the package intimately. Of course, much of that is postfix and
setting up the mail configuration which packaging is not going to help.
Ah. If I understand the buildit.sh script it's actually a
download-configure-build-install script, all rolled into one. One could
also say that the script solves a configuration management problem
(version X of SW A requires version Y of SW B, etc). That sort of
homegrown convenience is nice for people who'd like to install manually,
but it does add some work for the person trying to put together a Debian
package.
yes. I am willing to sacrifice raging dormouse because it is a pain in
the butt to maintain. While there is some degree of investment in a
"machine independent" form I think that creating a deb and telling
people to use alien for all others is not a hideously bad solution.
AFAIK it's not common to download the source during the building of a
package. You'd have to write quite some specific rules to handle any
patching to the code that's necessary. Exactly how you'd do that when
the build script doesn't separate download, configuration, build and
install is beyond me. There's also a problem with versioning, for the
life time of the Debian package you have to make sure that the exact
releases of each piece is available from a particular location. If you
look at Gentoo that's a problem that they've solved by throwing their
own storage space at it (which BTW means that if you're having problems
finding an old release of some SW then Gentoo is a great place to start
looking :-).
like I said, I'm not married to the the current install process. I am
quite content with the idea of building a traditional debian package
complete with dependencies. I just need to get a handle on installing
Python code in "its own directory".
This raises the question. Much of the code is firmly rooted at
/usr/local/camram/ I assume it's okay to keep that dependency in place
and not make it something that can be installed anywhere?
If I would try to package this piece of SW I think I'd start with
repackaging it. Download all pieces, unpack them in sub-directories.
Then I'd add a build system (probably a Makefile :-) that uses the build
systems of the pieces and adds any high-level tasks that need to be
performed. I'd make sure the Makefile separates configuration, build and
install. After verifying that this whole thing works I'd tar the whole
thing together and use this behemoth as a base for my Debian/Ubuntu
packaging.
here's my bias. I would download each of the individual pieces, build
individual if they do not already exist in the universe somewhere, and
make them all available. Instructions with them tell the user to build
their own local repository in the filesystem and install that way.
Unless of course there is a way of installing packages directly (dpkg??)
without the overhead of setting up a local repository. Alternatively,
support a repository for them. Well, actually have savanna support a
repository for them.
I would need to expand my knowledge beyond the simplistic use of dh_make
in order to build all these packages. Care to be my mentor? I do have
a clue every odd Thursday.
--- eric
--
ubuntu-users mailing list
ubuntu-users@xxxxxxxxxxxxxxxx
http://lists.ubuntu.com/mailman/listinfo/ubuntu-users
|
|