Calamares 1.0 Distribution-Independent Installer Framework Released

[curaga]

It's just an installer framework. Used only during installation and it can install Qt and GTK based desktops equally fine. No need for the outdated KDE vs Gnome purism wars here.

The size added by the installer matters. If all that bloat means (for example) 50mb larger installer, that's 50mb less for installable software.

[cocklover]

but why? what problem has to be resolved with a new development? It will be better for KDE distro maintainers submit fixs to KDE bugs detected for his users. A new installer is not really needed, at least i never had any problem installing KDE distros. But I have bugs on every distro KDE used, since the first KDE version used 4.4 and some of them are still present. Right know I'm waiting for a synaptic replacement in qt, but is not really needed, I can use synaptic in kde(Mint). I rather have more gui tools for manage the distro like I have on Windows

[r_a_trip]

The size added by the installer matters. If all that bloat means (for example) 50mb larger installer, that's 50mb less for installable software.

I still don't see the problem. Linux is an OS that practically assumes network connectivity. What isn't in the DVD iso can be downloaded from the repository.

[duby229]

As far as this universal package installer... Um, does anybody else think packages should have been containerized a long time ago? The underlying distribution wouldn't matter so much if packages were installed and executed straight from the package.

[pythoneer]

As far as this universal package installer... Um, does anybody else think packages should have been containerized a long time ago? The underlying distribution wouldn't matter so much if packages were installed and executed straight from the package.

but you don't want every program to ship with its own version of every lib or at least no updateable version of it. package managers are good for delivering security updates but bad for 3rd party devs to deliver one package/bundle/binary/whatever that runs on every distro but don't ship with all the libs. if you ship all the libs there should be a mechanism to "register" these libs to the system package manager so it can be updated and shared by other programs and if you don't ship them the package manager needs to pull down these libs in all versions out there and must deliver a way to use them side by side. this is really a hard problem. the "solutions" out there win/osx/linux are only on one end: either ship all libs and fuck security (win, osx) or you go through the dependency hell and build you program for every single distro in every single version out there. You are not building for linux, you are building for Ubuntu 12.04 and Ubuntu 14.04, Fedora 21 etc. we need something to combine the best of these two worlds. Ship a "bundle" that runs on all distros but don't introduce security holes if that bundle and its libs don't get updates (e.g. the programmer quit to maintain its own program)

Its "nice" that the distro package maintainers do so much work in maintaining the packages but it should not be their responsibility .. at the end they "own" the software rather than giving a platform on which others can run their software. If i write software for "linux" i need a kind maintainer on every distro to ship my software downstream. in my opinion this is not the way it should be in every situations. i really honor the hard work of the maintainers, but in my opinion they are not responsible of every shitty (my) software for they distro.

jm2c

[duby229]

but you don't want every program to ship with its own version of every lib or at least no updateable version of it. package managers are good for delivering security updates but bad for 3rd party devs to deliver one package/bundle/binary/whatever that runs on every distro but don't ship with all the libs. if you ship all the libs there should be a mechanism to "register" these libs to the system package manager so it can be updated and shared by other programs and if you don't ship them the package manager needs to pull down these libs in all versions out there and must deliver a way to use them side by side. this is really a hard problem. the "solutions" out there win/osx/linux are only on one end: either ship all libs and fuck security (win, osx) or you go through the dependency hell and build you program for every single distro in every single version out there. You are not building for linux, you are building for Ubuntu 12.04 and Ubuntu 14.04, Fedora 21 etc. we need something to combine the best of these two worlds. Ship a "bundle" that runs on all distros but don't introduce security holes if that bundle and its libs don't get updates (e.g. the programmer quit to maintain its own program)

Its "nice" that the distro package maintainers do so much work in maintaining the packages but it should not be their responsibility .. at the end they "own" the software rather than giving a platform on which others can run their software. If i write software for "linux" i need a kind maintainer on every distro to ship my software downstream. in my opinion this is not the way it should be in every situations. i really honor the hard work of the maintainers, but in my opinion they are not responsible of every shitty (my) software for they distro.

jm2c

That sounds an aweful lot like winsxs though. Not a big fan of that Idea. Static binaries would be bad too, as you said, security fixes and so on.

I think the solution comes from a version controlled common runtime environment. Instead of targeting distributions with their library dependencies, target a version controlled common runtime with it's library dependencies. From that base point everything else could be containerized. Then the only dependency is the version of the runtime that was targeted.

[pythoneer]

That sounds an aweful lot like winsxs though. Not a big fan of that Idea. Static binaries would be bad too, as you said, security fixes and so on.

I think the solution comes from a version controlled common runtime environment. Instead of targeting distributions with their library dependencies, target a version controlled common runtime with it's library dependencies. From that base point everything else could be containerized. Then the only dependency is the version of the runtime that was targeted.

As i mentioned the win approach (thus the winsxs crap) is one end of both sides. The winsxs approach does nothing more than throw every crappy lib in a huge unmaintainable bucket and forget about it – and dare you to clean up this mess! you have to reinstall your system

The approach you mentioned reminds me on the latest one from Gnome. There is nothing wrong with this at the first place – we can see that in action on Steam – to maintain a runtime that every distro has just to install besides their own packages. but what is with libs not maintained in the runtime? are they to minor to think about so everything beyond the runtime needs to be statically linked or as shared lib with rpath "hacks"? or is it necessary to maintain something like "maven", "npm", "gems", "homebrew", "biicode" ... for that runtime to A) register your lib_xy_v1.2 as lib vendor on that repo so that B) every programm can fetch their desired version from there and is sure about that fact, that its maintained.

so there is no need for 10 distro maintainers to maintain lib_xy_v1.2 on their distro. they can maintain it on this "global" runtime and everybody can benefit from this regardless which distro one uses.

But then you have the problem that you need to be online to fetch that packages if you want to install a program which has libs to be fetched

[duby229]

As i mentioned the win approach (thus the winsxs crap) is one end of both sides. The winsxs approach does nothing more than throw every crappy lib in a huge unmaintainable bucket and forget about it ? and dare you to clean up this mess! you have to reinstall your system

The approach you mentioned reminds me on the latest one from Gnome. There is nothing wrong with this at the first place ? we can see that in action on Steam ? to maintain a runtime that every distro has just to install besides their own packages. but what is with libs not maintained in the runtime? are they to minor to think about so everything beyond the runtime needs to be statically linked or as shared lib with rpath "hacks"? or is it necessary to maintain something like "maven", "npm", "gems", "homebrew", "biicode" ... for that runtime to A) register your lib_xy_v1.2 as lib vendor on that repo so that B) every programm can fetch their desired version from there and is sure about that fact, that its maintained.

so there is no need for 10 distro maintainers to maintain lib_xy_v1.2 on their distro. they can maintain it on this "global" runtime and everybody can benefit from this regardless which distro one uses.

But then you have the problem that you need to be online to fetch that packages if you want to install a program which has libs to be fetched

I think you're probably right.

Personally I wouldn't worry too much about back porting security fixes or bug fixes. If application developers don't want to keep their code updated against the latest version of the runtime, then it is their own fault when their application falls out of use.

On the other hand, If a significant group of contributors got involved it might be reasonable to at least back port security fixes. Something like gentoo GLSA.

[Luke_Wolf]

Well, in ideal world distros would only be a concept for defaults, everything would be in common package repositories, API/ABI guarantees would be globally agreed on. Tight dependencies avoided as possible and solved through shims and such. GNU/Linux as is is not exactly an inviting platform in all of its fragmentation. It's just silly how many people seem to think forking will resolve issues. With good package system and proper alternatives support there shouldn't be a need to fork ever, just provide alternative package and a mechanism exists which user can use to choose between even packages with identical versions

You know.... That sounds a lot like https://www.freebsd.org/

[anda_skoa]

As specified by the LSB, they're called RPMs

The problem is that unless you statically link everything in, which you'll be yelled at for, distros are too different at the core for sharing packages between distribution families.

Not necessarily.
The problem with LSB RPM is that people wrongly assume that they need to be installed by the system package tool, especially by people on an RPM based distribution.

The LSB defines RPM as the package format, but the packages should be handled by each distribution's LSB RPM tool.

That approach has several advantages:
- it doesn't need to require running as root, the LSB installation directory can have very different permissions to the system's main installation tree
- such a package can only ever negatively interfere with another LSB package
- installation can be made accessible to users who would not be granted system level installation priviledges.

It is closer in concept to who the steam runtime works.
A well defined base platform that 3rd party developers can target but which can be provided by distributions in anyway they see fit.

Cheers,
_