Don't Let Autopackage Die!
Rykel™
Jan Niklas Hasse
On Mon, Aug 9, 2010 at 2:44 AM, Rykel™ <ryk...@gmail.com> wrote:
> Hi gang,
> I am so glad that you are still working on/discussing Autopackage.
> Please do not let it die!
> Autopackage is the ONLY user-friendly installer that allows a person to
> install programmes without touching Root account and works across distros.
What about ZeroInstall or Listaller?
> What is important now, in my humble opinion, is to make Autopackages play
> nicely with the default Package Manager (apt/yum etc.) so that the distros
> can accept it.
That's true, but the problem can be descriped in one single wort: Bash!
While the language was a good choice when Autopackage was created,
today it's causing Autopackage's development to stagnate. The code is
ugly and unmaintable due to Bash being the wrong language for this
kind of big project. Global variables all over the place,
intransparent program execution, functional programing, ...
Let's be honest: Autopackages main code base is a mess! It's hard for
new developers to really understand how it works. All of this could
have been avoided by using a clean object orientated design from the
start using a language like C++, Python, C#, Java, Ruby - even C with
GObject would've been a better choice! If i think of it, it might have
been the best, since it doesn't require a interpreter or VM and we
could write new code in Vala today.
That's the reason why Autopackage will die! Or at least be completely
new written/designed which I doubt since the lack of developers.
Also keep in mind that distributions like Ubuntu don't WANT an
universal package format. They probably won't admit it, but think for
a second: Have you ever really used a distro which didn't use deb or
rpm? No? Why is that? For me it's simple: I have to compile many
programs from source since there's no package for them.
So the fact that many third party applications only provide deb and
rpm packages becomes an advantage for the distros using those formats.
Why should they give up on this advantage? With PPAs Ubuntu is taking
this a step further: It only works with Ubuntu, so if you want all
those fancy features, use it!
Imagine someone would create a package format which works on both
Windows and OSX. What do you think Microsoft would say? "Great, now
the user can choose which operation system he likes more"? Hell no!
Now replace Windows with Ubuntu and OSX with your favorite
non-deb-distro.
Ubuntu is using its monopoly in the linux distro market. Many people
use Ubuntu NOT because its the best distro but because the most
application work on it. Just as Windows.
-
Jan
Damjan Jovanovic
> Hi Rykel,
>
> On Mon, Aug 9, 2010 at 2:44 AM, Rykel™ <ryk...@gmail.com> wrote:
>> Hi gang,
>> I am so glad that you are still working on/discussing Autopackage.
>> Please do not let it die!
>> Autopackage is the ONLY user-friendly installer that allows a person to
>> install programmes without touching Root account and works across distros.
>
> What about ZeroInstall or Listaller?
Does Listaller allow non-root installs? I doubt it.
Zeroinstall user friendly? The website is too technical and the
runtime is hard to install.
>> What is important now, in my humble opinion, is to make Autopackages play
>> nicely with the default Package Manager (apt/yum etc.) so that the distros
>> can accept it.
IMHO we should stop installing to /usr and install to /usr/local
instead. Almost everything works in /usr/local nowdays, especially on
Ubuntu. That should evade the package manager nicely.
We should autopackage everything then, and get it to work on all
distros, removing Ubuntu's advantage ;-).
> -
> Jan
>
Damjan
Taj Morton
Thomas Leonard
> On Mon, Aug 9, 2010 at 1:43 PM, Jan Niklas Hasse <jha...@gmail.com> wrote:
>> Hi Rykel,
>>
>> On Mon, Aug 9, 2010 at 2:44 AM, Rykel™ <ryk...@gmail.com> wrote:
>>> Hi gang,
>>> I am so glad that you are still working on/discussing Autopackage.
>>> Please do not let it die!
>>> Autopackage is the ONLY user-friendly installer that allows a person to
>>> install programmes without touching Root account and works across distros.
>>
>> What about ZeroInstall or Listaller?
>
> Does Listaller allow non-root installs? I doubt it.
>
> Zeroinstall user friendly? The website is too technical and the
> runtime is hard to install.
Right. Making installation easy for your average user is what
Autopackage should be adding. What about writing a simpler set of
instructions, like the ones at:
http://autopackage.org/howtoinstall.html
Actually, those instructions apply to 0install bundles fine as they are!
Then, change the 0export tutorial to tell people to create bundles
called *.package instead of *.sh, call it "Autopackage 2" and you're
done ;-)
OK, I'm joking a bit. But isn't there some way this project could
provide a friendlier interface to some other system, if it technically
does what you need?
(BTW, I will eventually get around to sorting out the tutorial on
0install.net. It is way too technical.)
--
Dr Thomas Leonard http://0install.net/
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA
Mike Hearn
Just a little feedback on this from one of the (older) developers: IIRC, bash was chosen because it was (is?) the only language that is guaranteed to work on every Linux distro.
- Compatibility. These days you can probably assume a Python is present, but not back then. And which Python do you get? They aren't fully compatible with each other unfortunately.
- Familiarity for packagers. Autopackage exports an API and it needs to be easy for a packager to use it. Ugly though it is, bash is the lingua franca of Linux developers, and it makes common install-related operations like copying files around very concise.
- Architecture neutral, works on x86, x64, arm etc.
Jan Niklas Hasse
great discussion already :)
On Mon, Aug 9, 2010 at 3:34 PM, Damjan Jovanovic <damja...@gmail.com> wrote:
> Does Listaller allow non-root installs? I doubt it.
>
> Zeroinstall user friendly? The website is too technical and the
> runtime is hard to install.
But I think both things are easier to fix than adding PackageKit
support to Autopackage.
> IMHO we should stop installing to /usr and install to /usr/local
> instead. Almost everything works in /usr/local nowdays, especially on
> Ubuntu. That should evade the package manager nicely.
Some things like libraries (pkg-config, etc.) still have problems IIRC.
> We should autopackage everything then, and get it to work on all
> distros, removing Ubuntu's advantage ;-).
Creating an Autopackage is harder then creating a deb (apbuild,
binreloc, redundant install section, ...), so I don't think we will
ever catch up with Ubuntu.
On Mon, Aug 9, 2010 at 4:29 PM, Taj Morton <tajm...@gmail.com> wrote:
> Just a little feedback on this from one of the (older) developers: IIRC,
> bash was chosen because it was (is?) the only language that is guaranteed to
> work on every Linux distro. C++ had ABI issues, Python, Ruby, Java, and C#
> have far too many different incompatible versions (or aren't installed by
> default) on some distros. C would have been the other obvious choice, but
> the glibc symbol issue (worked around by apbuild) could have caused issues.
True.
> I'll definitely agree that the code is giant and a bit spaghetti, but would
> warn anyone against choosing an uncommon language (or one with issues) for a
> new project. For a non-native package manager to work on all distros, you
> need your code to run without all problems on every distro. Unfortunately,
> the only language I know of that's more-or-less guaranteed to exist (without
> major incompatibilities) is bash. I'll admit I've been pretty out of the
> loop wrt the status of Linux binary compatibility, so it's possible that
> glibc and g++ are more stable now and C/C++ wouldn't cause as many issues.
C++ might still be problematic and I wouldn't count on newer GCC
versions not changing the ABI again.
But C binary compatibility seems to be quite stable now.
One thing to keep in mine: Autopackage's frontends and some helper
utilities are written in C anyway!!
On Mon, Aug 9, 2010 at 9:52 PM, Mike Hearn <mi...@plan99.net> wrote:
> Compatibility. These days you can probably assume a Python is present, but
> not back then. And which Python do you get? They aren't fully compatible
> with each other unfortunately.
You could include your own interpreter, which would be quite big then though.
ZeroInstall for example is using Python and it survived ;)
> Familiarity for packagers. Autopackage exports an API and it needs to be
> easy for a packager to use it. Ugly though it is, bash is the lingua franca
> of Linux developers, and it makes common install-related operations like
> copying files around very concise.
Right, but bash could still be used for post/pre install scripts and
the rest can be written in another language (dependency handling,
copying files, ...). Deb-Packages work like this if I'm not mistaken.
> Architecture neutral, works on x86, x64, arm etc.
But Autopackage was x86-only a long time. Today it still doesn't work on ARM.
Also as I said before things like the frontend are written in C anyway
so they need to be ported.
> There were some other reasons that don't apply anymore, for instance, when
> autopackage was started dialup internet was still common and I wanted the
> overhead to be extremely small. Bash is, despite its faults, remarkably
> concise especially when compressed. Try writing some equivalents of the
> larger functions in C or C++ and you'll find it takes a lot more space.
Okay, that's a good reason indeed.
> But, I wouldn't write autopackage today. I don't know if you saw the recent
> report from some university in the states, where they survey the OS freshmen
> use. Linux usage peaked at 2.4% in 2004 and has now declined into non
> existence.
I found other numbers after googling a little bit:
http://www.tgdaily.com/software-features/41291-report-windows-losing-market-share-fast-to-mac-and-linux
> If you want to have an impact, I'd definitely suggest focusing on the web.
> Desktop Linux apps are yesterdays technology and probably not worth spending
> any more time on.
True! Especially with smart phones and stuff which bring their own app
distribution service.
For game developers there will be Steam for Linux in the future, which
does also use it's own installation system.
Damjan Jovanovic
Maybe my comment was a bit harsh, sorry.
Basically I was playing with ZeroInstall a few months back. I went to
the website, "Download/Install" -> "Linux", all the packages needed
root access to install (unlike autopackage). I didn't want to do that,
so I went to "get the source package instead", this took me to a
complex page (http://zero-install.sourceforge.net/install-source.html)
and I typed the commands listed, but had various problems like
commands not in $PATH, menu icons missing, and it just didn't leave me
with a good impression.
Damjan Jovanovic
> Hi everyone,
>
> great discussion already :)
>
> On Mon, Aug 9, 2010 at 3:34 PM, Damjan Jovanovic <damja...@gmail.com> wrote:
>> Does Listaller allow non-root installs? I doubt it.
>>
>> Zeroinstall user friendly? The website is too technical and the
>> runtime is hard to install.
>
> But I think both things are easier to fix than adding PackageKit
> support to Autopackage.
>
>> IMHO we should stop installing to /usr and install to /usr/local
>> instead. Almost everything works in /usr/local nowdays, especially on
>> Ubuntu. That should evade the package manager nicely.
>
> Some things like libraries (pkg-config, etc.) still have problems IIRC.
>
>> We should autopackage everything then, and get it to work on all
>> distros, removing Ubuntu's advantage ;-).
>
> Creating an Autopackage is harder then creating a deb (apbuild,
> binreloc, redundant install section, ...), so I don't think we will
> ever catch up with Ubuntu.
We could target new/important/rare applications. For example one of
the DC++ applications (I think ApexDC?) is making a Linux port at the
moment - it will be the *only* DC++ application that has a Linux
version. We could approach them and offer to help them autopackage it.
Developers and users installing it will learn about autopackage, and
hopefully over time start making autopackages of other applications
and demanding distributions support autopackage.
Also what applications do you guys use but find hard to install (eg.
older versions of GCC)? We could autopackage them, so autopackage
becomes the only easy way to install them.
LLVM could be used to make architecture neutral binaries. The only
problem is that LLVM bytecode is easy to convert back into C, so it
might not be popular with commercial applications.
>> There were some other reasons that don't apply anymore, for instance, when
>> autopackage was started dialup internet was still common and I wanted the
>> overhead to be extremely small. Bash is, despite its faults, remarkably
>> concise especially when compressed. Try writing some equivalents of the
>> larger functions in C or C++ and you'll find it takes a lot more space.
>
> Okay, that's a good reason indeed.
>
>> But, I wouldn't write autopackage today. I don't know if you saw the recent
>> report from some university in the states, where they survey the OS freshmen
>> use. Linux usage peaked at 2.4% in 2004 and has now declined into non
>> existence.
>
> I found other numbers after googling a little bit:
> http://www.tgdaily.com/software-features/41291-report-windows-losing-market-share-fast-to-mac-and-linux
That's a 2009 study. Windows 7 is really selling now and Microsoft is
reporting record profits
(http://mybroadband.co.za/news/business/13978-Microsoft-reports-record-high-sales.html).
After the disaster that the past few Ubuntu releases have been
(especially Karmic), many Linux users I know have changed to MacOS or
gone back to Windows. Even Internet Explorer's market share has been
*rising* lately.
I think the best way to cash in on Microsoft's success is to improve
Wine, which is why it's the open source project I've been contributing
to the most.
>> If you want to have an impact, I'd definitely suggest focusing on the web.
>> Desktop Linux apps are yesterdays technology and probably not worth spending
>> any more time on.
>
> True! Especially with smart phones and stuff which bring their own app
> distribution service.
>
> For game developers there will be Steam for Linux in the future, which
> does also use it's own installation system.
>
The death of the PC has been predicted almost since it was invented,
yet they just keep selling :-).
And do you really want the future to belong to web apps?
Damjan
Thomas Leonard
[...]
> Basically I was playing with ZeroInstall a few months back. I went to
> the website, "Download/Install" -> "Linux", all the packages needed
> root access to install (unlike autopackage). I didn't want to do that,
> so I went to "get the source package instead", this took me to a
> complex page (http://zero-install.sourceforge.net/install-source.html)
> and I typed the commands listed, but had various problems like
> commands not in $PATH, menu icons missing, and it just didn't leave me
> with a good impression.
I've added a note that you need to log out and back in again. I know
you guys are no strangers to
https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/191958
This will automatically update $PATH to include ~/bin (Ubuntu checks
for its existence at login time) and make the menu update. I didn't
test whether the icon installs correctly for a --home install on the
last release because I know that changed recently. It works for me in
Git. I also got it to add ~/lib/python to sys.path in the scripts, so
it finds them. I thought this was now the default, but it seems even
Python 2.7 doesn't look there, even though that's where its own
distutils installer puts them by default!
In summary, it should work now! Could you test it:
$ git clone git://repo.or.cz/zeroinstall.git
$ cd zeroinstall
$ python setup.py install --home ~ --install-data ~/.local
Log out and back in again. It should now:
- Appear on the menu, with the right icon (a better icon than before, in fact!)
- Work if you run it, even if you ignore the instructions about
setting $PATH and $PYTHONPATH
[ Of course, most Ubuntu users just click the big green button on the
main page and install as admin. But installing to $HOME should still
be as easy as possible. ]