> This just seems to be a complex enough case that it's simply not a good
> target for this packaging system. I'm OK with that. As I said, this is
> not trying to be a complete replacement for debs, because if it tried to
> do that it would rapidly turn into a second system with a different set
> of flaws.
Sad to hear that... Debs (and Rpms) is a reason why bug #1 will not be
solved in foreseeable future. Thus, developers still needs to create
their ugly or use 3rd-party installers which act on system or homepage
without limitations because root/sudo password, users need do manual
changing execute bit with entering sudo password which is not
convenient and hard for regular users.
Solution which I suggest is dependency-free and it only seems as
complex, but actually just encapsulates your packages (and it's OK
that they are read-only) into single one. It would be very convenient
to have them in single place instead downloading and installing
separate 5-10 packages of some software which have components,
especially when some of them logically required.
The only simple things required is to provide additional file
extension for such pure-declarative installer and GUI itself (with
possibility to install from CLI).
Just imagine, developer will want to deploy Mono-based application.
Such package can contain Mono runtime package + application package
itself. What if Mono-runtime of _exact_ version already installed with
your packaging system? Then just mark in installer GUI that this
required component already installed. And what if other application
will want same runtime of same version? No problems. What if version
differs? Then it installs another one alongside with current. And
Java? And Python, let's assume it's not preinstalled because we need
2.7 and Ubuntu provides 3.x, or it's old package which needs to be
installed on Ubuntu 22.04 where only Python 4.x available...
Let's don't repeat Android's errors, look at how Qt-based applications
deployed for this platform. When user attempts to run application it
prompts user to install huge additional component through market. And
what if user out of network coverage or in expensive roaming network?
Noting bad in dependencies itself, it's just bad Linux's
implementation contains flaws:
1) Can't install under user, because files writing in system paths.
2) Can't install many versions of same library, because library space is flat.
3) Packages for APT/RPM does not contain necessary dependencies.
Look at ZeroInstall - it's nice except dumb deploying experience of
stand-alone network-free packages (absence of which - main drawback of
Ubuntu and other Linux-system in part of software management), because
we need to create package which contains non-declarative parts which
should be run with password, because ZI not installed in Linux system
by-default, and we need to set executable bit... Insane.
Ideal solution: do users and developers at least same level of
possibilities at least as in Mac OS X.
It's not late to create such package management system, or at least
PLEASE, don't say "it will never be in Ubuntu".
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel