On Sun, 2007-08-05 at 11:05 +0200, Sebastian Heinlein wrote: > Take a look at these similar projects: > > https://wiki.ubuntu.com/APTonCD > > https://wiki.ubuntu.com/ThirdPartyApt > 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 https://wiki.ubuntu.com/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 (https://wiki.ubuntu.com/OfflineUpdateSpec ) 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 are: 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 mentioned. Thanks, Chris Warburton -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
