Re: Easy third-party package installer for debian-based distributions
On Mon, Sep 19, 2005 at 04:10:00AM +0200, Sami Dalouche wrote:
> Sorry for being concerned with usability issues (hence average joe) while
> dealing with the way debian works. I guess that only ubuntu-devel was
> interested by this message then.
I'm not saying that.
What I'm saying is that I've seen many, many such scenarios that were
all based on how a hypothetical average joe is going to work with his
Debian-based computer, without actually checking things with reality
first. Unless you know an average joe who'll be interested in installing
a .deb by double-clicking on it, I don't think there's much value in
coming up with a solution for that 'problem'.
The way I see it, people who'll want to install third-party software
* be competent enough to do it by themselves (and won't need nor use any
graphical tools to help them),
* have an LSB package they want to install (hence, a framework for
automatically adding lines to /etc/apt/sources.list is quite useless
* have a tarball they need to unpack over their / filesystem (or in
their /usr/local, or whatnot), or
* have a computer-savvy neighbour whom they'll ask to do it for them.
I don't think it's likely that there'll be many people who'll download a
.deb, feed it to the packaging system through some GUI, and expect it to
work; so IMO it's not worth the effort to create a framework that will
allow this. And even if it was, it's possible to make it possible to
install a .deb by using the tools already there, and just modifying
the relevant .desktop file.
> I am not claiming that synaptic is hard to use, (it can even be easier in some
> use cases), I am just claiming that adding a third party repository can be
> difficult for a newcomer, and my post was about trying to find an acceptable
> solution to this problem.
You've failed to do that, IMO.
Everything is difficult to newcomers. Always has been, always will be.
The correct way to help them out is not to hide away features inside
obscure binary files, hence adding more complexity for your users to
understand the bigger picture, but to make it easier for newcomers to
> And yes, maybe third party are not competent enough to provide decent packages.
> but if we don't even provide a framework they can build upon, they are never
> going to use it...
> So, as a summary :
> - apt-get & dpkg solutions don't fulfill all the requirements :
> 1) Does not subscribe to future updates
> 2) Does not allow the third party entity to provide several packages
> - some people spoke about autopackage. I would be pleased to hear about some
> links detailing how autopackage plans to integrate with apt/dpkg.
autopackage is a bad idea:
* It overwrites files in your package management-managed system,
* It does not interact with the package manager to register and
Hence, it's a very likely source of hard-to-trace bugs (becuase the
package foo you're using is differently compiled from the package dpkg
thinks is installed and from the package bar, which uses foo, expects to
find). Don't use it.
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond