> 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 ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
