Feedback Request for Prototype Package Tool

Chris Warburton chriswarbo at
Sun Aug 5 15:02:48 UTC 2007

On Sun, 2007-08-05 at 11:05 +0200, Sebastian Heinlein wrote:
> Take a look at these similar projects:
I have emailed the lead developer of APTonCD a while back to discuss
either adding this functionality to APTonCD or sharing code (since their
implementation seems much nicer) and he agrees that it would be
sensible, since there does seem to be some duplication of effort, but
the main problem here is that I do not understand the APTonCD code (I am
very new to programming in general). Therefore I am stuck with my
implementation at the moment, which is still a prototype, and maybe
after some more experience I can ditch it in favour of APTonCD in the
future. The main problem I have with APTonCD on the whole is that it
seems to do too much, resulting in a complex interface. I am interested
in UI design and my own tool has gone through a few revisions before I
realised that all of the functionality needed could be done with 4 text
boxes, a check box and 2 buttons. The backend code, however, could
benefit a lot from APTonCD.

> Furthermore the "transportable" repositories do not seem to address your
> basic problem: the not availability of a package for a specific piece of
> software.
Admittedly this is a major problem, but I have not had enough experience
with packaging to make an automated tool for it (something like AutoDeb ), and I'm sure an automated packaging
tool like that would have serious issues with guidelines, etc. (Which is
why the only packages my tool makes are tiny metapackages which don't
contain any files to install, I am paranoid of breaking systems).

This was not an issue originally, since it stemmed from an idea
( ) about putting all available
updates into an archive which could be used across many machines (like
APTonCD can do, but this discussion was before APTonCD was around),
hence the "service pack" idea, so all the packaging had already been
done by the distro. However, I didn't like the implementation idea since
a) I felt it was introducing yet another software installation method
when APT could do the job, b) the same basic tool could be used for more
situations (the use cases on the TransparentServicePackMaker page) and
c) needing to use the tool itself to install the packs put an
unnecessary restriction on those who could use the output. That is why I
used the name "transparent", since it does not create any extra steps on
behalf of the user. Whilst it doesn't really make life any easier for
developers and packagers using it for their software as you say, it
should make the lives of the end users installing the packs easier. I
did bring this up on the OfflineUpdateSpec page, but felt it was very
much a "show me the code" situation, so now that I am learning to
program I decided to do that.

> And always keep in mind that installing third party software or locally
> compiled software has not gone through the Ubuntu quality assurance
> process.

This is an issue, of course, but the two main areas I see it useful in
1) Its original use of making collections of updates, these packages are
taken from the Ubuntu archives (or whatever other sources are enabled)
so no extra problems should be introduced.
2) Proprietary software which cannot be included in Ubuntu, especially
games. At the moment non-free game installation is a painful process (I
couldn't run the game Gish for about 6 months before I eventually found
out that all I needed was the libalut0 package!) and admittedly the
biggest obstacle to decent packages is the cross distro problem (being
tackled by the LSB), but by using this service pack maker anyone who has
already packaged something for Ubuntu like a game can include any
libraries and things along with it on a CD or in a download safe in the
knowledge that everything needed to run their software has been given to
the user and they won't need to install multiple package files manually,
they don't require an Internet connection, etc.

I appreciate the comments, and I am concerned with the duplication issue
with APTonCD, but this is still just a proof of concept and I would be
happy to work with APTonCD developers in the long run on either tool,
once I am able. As for the third-party packaging issues, this is aimed
at making users' lives easier, I wouldn't tackle automating the job of a
packager since I am not experienced enough with packaging and wouldn't
want to create headaches for users of such packages.

Sorry if I seem to dismiss the comments, I do take them on board but I
have been thinking a lot about this already including some of those

Chris Warburton

More information about the Ubuntu-devel-discuss mailing list