Dne 16.9.2014 v 16:39 Miloslav Trmač napsal(a):
----- Original Message -----
Dne 16.9.2014 v 12:21 Richard Hughes napsal(a):
On 16 September 2014 10:55, Zdenek Kabelac <zkabe...@redhat.com> wrote:
Just a thought - but wouldn't be better spend time to enlighten
Gnome/Firefox developers how to write applications in a way the could be
upgraded runtime
So, it's not just the application, it's every application and D-Bus
service the application uses. Even glibc opens files-as-resources at
So it's time to fix D-Bus then as well!
If something is broken - it will not get fixed by hiding broken design behind
reboot&upgrade.
Quite true.
If you can't fix the Firefox (or some other broken tool) and you want to allow
install of new version - then you need to allow i.e. parallel installs of such
packages - it's that simple - I've been doing this more then 15 years ago at
University - so really nothing new here...
Well, what we would need is:
1. Ability to keep multiple versions (both ABI-compatible and ABI-incompatible)
of a single application or library or service installed and running at the same
time.
Other distributions allow to install multiple version of same libraries - I've
never understood the Fedora policy to recompile whole Fedora when a new
version of library is released.
This policy design is quite 'show-stopper' for anything like this...
2. Ability to detect which processes depend on which versions of which
components.
We already managed to brought in systemd....
3. Ability to automatically restart such processes without loosing state
(either completely transparently or with some user notification for GUIs).
I'm not quite sure why we would need restart - simply delayed lazy release of
unused packages would do the trick here - doing here state-full design is much
more complex thing....
The primary use-case to target should be to allow reinstall user packages
while they are in use.
This has all been done before, and can be done again. (And it would make at
least half of the userbase clamoring for containers what they need, without
playing ugly complex nontransparent namespace games.) But let’s be clear about
it, 1. means completely changing our filesystem layout, and 3. means changing
our process model to go way beyond int main(...).
It is technically possible, it is the right thing to do. Do we want to do it
and can we do it?
Fedora made not much useful /usr move thing - so maybe it's time to think and
design something really useful.
As mentioned there are OSes which do handle things much better...
And surprisingly even Systemd guru realized there is something broken with
current filesystem layout - except solving it with Btrfs is not really a fix...
Has Fedora given up Unix ??
The Unix history is actually closer to “edit header files to match your
hardware, then rebuild the kernel and userpace with (make world), and reboot“.
Packaged applications with an ISV source and an update stream separate from the
OS have certainly been built on top of Unix but have never been a major design
focus. Arguably the whole point of a “Linux distribution” has been to get
closer to the BSD-style single-kernel-and-userspace distribution updated always
as a whole.
My view rather is - Fedora is taking feature-by-feature away from my box.
Zdenek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
