Autopackage for Ubuntu!

[thephotoman]

Point taken.  They could probably use to implement better naming 
conventions to resolve the issue.  However, efforts should be taken to 
make libraries forwards-compatible at the very least, so that I can run 
older software with newer libraries.  Sadly, that's frequently not the case.

Konstantin Ryabitsev wrote:
> On Sun, 30 Jan 2005 17:54:48 -0600, thephotoman <rantman_2000 at yahoo.com> wrote:
> 
>>Autopackage is already used for FOSS commercial software.  The GIMP has
>>a .package file out there, as does Gaim.  Frankly, I find it much easier
>>to keep up with Gaim using their .package than I do with the .deb
>>packages, as the autopackage comes out quicker (it's an official
>>package, so it releases with the source).  Furthermore, it doesn't even
>>blink with the dependencies...it just installs them--something that dpkg
>>doesn't do without apt-get.
>>
>>I frankly like it because it's universal.  Compile one binary nad
>>distribute it to those who don't want to deal with source, instead of
>>compiling multiple RPMs, a .deb package, ebuild, and tgz packages.
>>Furthermore, no worries about dependencies on any system, as previously
>>mentioned.
> 
> 
> Well, no, it's not correct to say that there are "no worries." You
> just haven't ran into them, but that doesn't mean that there aren't
> significant ones. Let's imagine the following scenario:
> 
> 1. You want to install application Foo, which depends on a library
> libbar 1.2. You manage to be lucky and find a .package file for libbar
> version 1.2. If you're not lucky, well, then you must install it via
> some other way, like download-make-install, or apt-get, or whatnot.
> 2. A while later you decide you also want to install an application
> Baz, which also depends on libbar, but on version 2.0. So, you upgrade
> libbar-1.2 to libbar-2.0 and your application Baz installs and works.
> 3. However, your application Foo now no longer works, because it
> requires libbar-1.2, but you forgot all about that. Since autopackage
> doesn't care about other applications already installed, it won't
> check if something breaks during a library upgrade.
> 
> The only solution with autopackage is to statically bundle all
> libraries, which brings its own set of problems with it, mainly size
> and security related.
> 
> So, while using autopackage is fine here and there for commerciall
> apps that statically link in all libs and for which a repository
> cannot be set up for whatever reason, you do not "escape all
> dependency worries" with it, as claimed.
> 
> Regards,