Listaller
Jan Niklas Hasse
What do you think of it? Can it replace Autopackage?
Since the recent lack of development in Autopackage I'm considering
becoming a Listaller developer. We could spread the word a little bit
and reuse Autopackage code (e.g. apbuild).
I'm awaiting your responses :)
Isak Savo
>
> Anyone heard of Listaller? Check it out: http://listaller.nlinux.org/
>
> What do you think of it? Can it replace Autopackage?
Absolutely
> Since the recent lack of development in Autopackage I'm considering
> becoming a Listaller developer. We could spread the word a little bit
> and reuse Autopackage code (e.g. apbuild).
> I'm awaiting your responses :)
Seems like a good idea. Autopackage is quite dead (at least is seems
so) and linstaller seems to build upon the PackageKit which I think
will give it better acceptance than autopackage ever got.
In my opinion, go for it :)
-Isak
Chris Giles
What do you think of it? Can it replace Autopackage?
Absolutely
I don't think Listaller can replace Autopackage, since it seems to be fundamentally different. I read through its website and learned that Listaller packages aren't executable like Autopackages.
This means that users who've never heard of it won't know what to do with an ".ipk" file; whereas, they don't need to know anything about Autopackage and can just execute a ".package" file from the shell.
Thomas Leonard
I'd imagine most things can be wrapped in a shell script if that's
what you want.
0install bundles are executable, like .package files, for example:
http://0install.net/0export.html
Also, 0install now supports PackageKit too, so it handles both
0install and native package dependencies with a single metadata
format:
http://0install.net/distribution-integration.html
It also supports the case where a dependency might be satisfied in
different ways on different platforms. For example, it might install a
distribution package on Debian, install a 0install binary on Fedora
x86, and compile from source on FreeBSD.
But, we didn't put much effort into the self-extracting archive's GUI.
If anyone wants to make it look slicker (i.e. more like autopackage),
patches are welcome!
--
Dr Thomas Leonard ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA
Jan Niklas Hasse
to the Listaller maintainer.
The wheel is reinvented a lot in projects like Autopackage, Zero
Install, klik, MojoSetup and Listaller. I hate that and would rather
work together, but it seems like I'm the only one who cares :(
I also dislike the idea of letting Autopackage die ... So many work wasted :'(
Gustavo Serra
Your work was precious for many people, I am sure. If the time has
come to let it go, opening the way for new things, then it was not a
waste, it is experience. A lot of maturity is necessary to think like
you, and I want to say thank you for all the work put into
autopackage.
2010/7/11 Jan Niklas Hasse <jha...@gmail.com>:
--
Serra
Damjan Jovanovic
Listaller uses the crazy idea of supporting each distro individually,
through the same package file; see
http://listaller.nlinux.org/docu/7-specs/23-ipk10-specs.html in
particular the part where you list dependencies *per distro*:
Dependencies[Ubuntu]:
http://dfn.dl.sourceforge.net/sourceforge/listaller/listaller_0.1.16a_i386.deb
(listaller)
Dependencies[openSUSE]:
http://dfn.dl.sourceforge.net/sourceforge/listaller/listaller_0.1.16a_i386.rpm
(listaller)
I think this approach also suffers from the problem of requiring all
installs into /, as root.
Damjan Jovanovic
> Thanks for your responses! I will think about it a little bit and talk
> to the Listaller maintainer.
>
> The wheel is reinvented a lot in projects like Autopackage, Zero
> Install, klik, MojoSetup and Listaller. I hate that and would rather
> work together, but it seems like I'm the only one who cares :(
I also care! There is so many third-party packaging projects, and it
seems they're all half-baked (eg. Autopackage doesn't display EULAs,
others aren't as binary compatible, etc.).
Maybe we should unify a few of these projects? The Zero install
project seems to have some good ideas and nice features, but also
lacks some (eg. the self extracting archive's GUI): Thomas, what do
you think about merging Autopackage and Zero install? One starts with
A and the other with Z, so hopefully together they have everything
from A to Z :-).
> I also dislike the idea of letting Autopackage die ... So many work wasted :'(
>
Instead of dying, let's merge Autopackage with other packaging
projects - we'd get more features, more developers, more users, more
packages, and a louder voice in the community.
Chris Giles
All of what you wrote seems good, but there's still the 'bloat' issue with ZI that I don't like. I don't want the shell archive to contain a copy of ZI; I want that to be downloaded at runtime instead, if necessary. This is how AP works and it keeps the ".package" file small. How quickly can you stuff this feature into ZI?
If you have a bunch of dinosaurs, who are lacking Internet connections and need ZI to be included, by all means keep them satisfied with a bloated shell archive. At the same time, at least give the rest of us the ability to switch that option off, keep the shell archive small and download any missing components at runtime.
Thomas Leonard
> Hi Thomas
>
> All of what you wrote seems good, but there's still the 'bloat' issue with
> ZI that I don't like. I don't want the shell archive to contain a copy of
> ZI; I want that to be downloaded at runtime instead, if necessary. This is
> how AP works and it keeps the ".package" file small. How quickly can you
> stuff this feature into ZI?
Well, ZI is the thing that does the downloading ;-) It's about 180 kB
compressed if you exclude the unit-tests and .po files, which aren't
needed to run it. It:
* Provides a GUI, showing download progress
* Has a console mode if there's no X Windows
* Checks the digital signature, using either GnuPG or GnuPG2
* Checks the fingerprint against the key-information server
(0install's key might have expired / been revoked since the package
was made)
* Switches to a mirror server if the main server is down
I don't think you'll get the downloader much smaller without losing
something important.
In general, the bundles will be larger than necessary anyway (e.g. we
often include 64-bit and 32-bit binaries in a single bundle, plus
copies of some libraries the user might already have). If you want to
minimise network use and you already have 0install, then you don't use
the bundle at all, you just point your existing 0install at the feed
and it downloads only what it needs.
But of course, it's all customisable. For example, the Sugar project
recently added the --net-install option (which does the opposite of
what you want; it bundles *only* 0install and the target application's
metadata, not the application binary itself).
> If you have a bunch of dinosaurs, who are lacking Internet connections and
> need ZI to be included, by all means keep them satisfied with a bloated
> shell archive.
These are exactly the people the bundles are for (and also for archiving).
> At the same time, at least give the rest of us the ability
> to switch that option off, keep the shell archive small and download any
> missing components at runtime.
This is the default mode. We want to discourage people from
downloading bundles if possible, because of the security issues.
Saving some download time might be another incentive ;-)
Does that solve the problem?
Chris Giles
Well, ZI is the thing that does the downloading ;-) It's about 180 kB
compressed if you exclude the unit-tests and .po files, which aren't
needed to run it.
I still don't think we're on the same page yet. I know you think 180 KiB is small, but consider that an AP ".package" file is only about 15 KiB larger than the source archive it wraps. This is because it's just a shell script that downloads all of the AP files at runtime.
It:
* Provides a GUI, showing download progress
* Has a console mode if there's no X Windows
* Checks the digital signature, using either GnuPG or GnuPG2
* Checks the fingerprint against the key-information server
(0install's key might have expired / been revoked since the package
was made)
* Switches to a mirror server if the main server is down
I don't think you'll get the downloader much smaller without losing
something important.
In general, the bundles will be larger than necessary anyway (e.g. we
often include 64-bit and 32-bit binaries in a single bundle, plus
copies of some libraries the user might already have). If you want to
minimise network use and you already have 0install, then you don't use
the bundle at all, you just point your existing 0install at the feed
and it downloads only what it needs.
Maybe you should allow the option to omit the bulky GUI files from the bundle, instead choosing to download them at runtime. This might avoid the need for separate 32-bit and 64-bit binaries, as you'd only need an AP-like shell script.
But of course, it's all customisable. For example, the Sugar project
recently added the --net-install option (which does the opposite of
what you want; it bundles *only* 0install and the target application's
metadata, not the application binary itself).
This could be good, once it lets us bundle nothing at all. I wouldn't mind shipping tiny shell scripts that download both ZI and the desired applications. Even if you don't like that idea, it would make ZI more flexible and that's what Linux is all about!
This is the default mode. We want to discourage people from
downloading bundles if possible, because of the security issues.
Saving some download time might be another incentive ;-)
Does that solve the problem?
Not really, for the reasons stated above. Also, I want to provide my end-users with shell archives, since many don't know anything about AP or ZI. I don't care much about security and neither do they. I just want a barebones installation script that wraps the source archives.
I would also want ZI to install my applications into a subdirectory of "/usr/share/". I know this voids your security principles, but I want my users to know where the application files are. This is because some of them include optional components that the users might want to toggle.
Jan Niklas Hasse
> Maybe we should unify a few of these projects? The Zero install
> project seems to have some good ideas and nice features, but also
> lacks some (eg. the self extracting archive's GUI): Thomas, what do
> you think about merging Autopackage and Zero install? One starts with
> A and the other with Z, so hopefully together they have everything
> from A to Z :-).
We don't need to merge them (since they are quite different in many
aspects), but working more together would be great. Thomas, what do
you think?
> Instead of dying, let's merge Autopackage with other packaging
> projects - we'd get more features, more developers, more users, more
> packages, and a louder voice in the community.
Yes this sounds great! I'm talking with the Listaller creator at the
moment, let's see what comes out of it.
Thomas Leonard
> On Mon, Jul 12, 2010 at 3:05 PM, Damjan Jovanovic <damja...@gmail.com> wrote:
>> Maybe we should unify a few of these projects? The Zero install
>> project seems to have some good ideas and nice features, but also
>> lacks some (eg. the self extracting archive's GUI): Thomas, what do
>> you think about merging Autopackage and Zero install? One starts with
>> A and the other with Z, so hopefully together they have everything
>> from A to Z :-).
>
> We don't need to merge them (since they are quite different in many
> aspects), but working more together would be great. Thomas, what do
> you think?
I agree. It might be worth making a list of features of Autopackage
that you miss in other systems and can't live without.
Some of the requirements expressed so far (e.g. must be a shell
archive, software must end up in a predictable location) seem a bit
more like implementation details to me. e.g. many users manage to
install Firefox extensions without any trouble.
Also, looking at possible reasons why it wasn't adopted. A number of
distributions now include 0install, and they mostly had the same
question when including it: does it have the same security/conflict
problems as Autopackage? A system that isn't used much can get away
with ignoring these issues, but distributions want to know it will
scale up.
I don't know if anyone has time, but it would also make sense to try
packaging something (e.g. apbuild) for various other installation
systems to see which ones work best.