Re: Improving the offline updates user experience

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- Original Message -----
> > 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

AFAIK only when the ABI (soname) is different.  We also need to allow for the case when the ABI stays the same but the internal implementation changes (e.g. changing a format of a resource file that is used by the library, making old processes incompatible with the newly installed resource).

> > 2. Ability to detect which processes depend on which versions of which
> > components.
> 
> We already managed to brought in systemd....

I can’t see how systemd helps.  See the other discussions about Python/Ruby modules that leave no obvious trace of their dependency after being loaded into memory.

> > 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....

Because otherwise you end up with an old version of Firefox running for 60 days (or however long a laptop can run with suspends and no restarts; most people about never quit their browser), and that version of Firefox keeping an old version of a system-wide daemon running for 60 days as well..

> And surprisingly even Systemd guru realized there is something broken with
> current filesystem layout - except solving it with Btrfs is not really a
> fix...

The sad thing is that adding more workarounds like namespaces and the like really might be easier than agreeing on making a real change and getting it done :(  But we will live with the costs forever.
    Mirek
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux