----- Original Message -----
> Dne 16.9.2014 v 17:08 Miloslav Trmač napsal(a):
> > ----- 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).
>
> That's what I mean - when something changes in the library - soname should
> change. It's quite broken to release same version of library with the same
> name when there is different internal implementation.
No. Let me try to explain the issue in detail.
libfoo-1.0.0 and libfoo-1.0.1 both use /usr/share/libfoo/magic_database, but
the internal format has changed between the versions. It is _internal_ so
changing the soname would be both unnecessary and _inappropriate_ (breaking
users). Looking at current packaging, neither RPM nor debian would install
libfoo-1.0.0 and libfoo-1.0.1 in parallel. Looking at the filesystem (i.e.
assuming that we can change packaging), we may have both /usr/lib*/foo-1.0.0.so
and /usr/lib*/foo-1.0.1.so installed on the filesystem, but that
/usr/share/libfoo/magic_database can only have only one of the versions. (OK,
in this case it could be argued that it is the upstream’s fault and that they
should version the magic_database path if they change the internal format, to
explicitly design for parallel installs. But now consider the distribution
patching the library (changing “release” as opposed to “version” in RPM
terminology); upstream can’t reasonably for that, parallel installation of
same-version-different-release packages must be a distribution-focused
filesystem design.
> >>> 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.
>
> It has similar complexity and maybe packages could be described just like
> services - so similar thing could be possibly reused here ?
Extra manual dependency information that would get obsolete?
> >>> 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..
>
> Sure if user is able to run Firefox for 60 days (though my usually goes out
> of RAM in just a week or so, if it's not crashing earlier...) - then he is
> happy user.
Until an exploit _that they have already installed an update for_ steals their
data.
> I guess something may show to user some nice gui dialog warning like - 'Hey
> there is a new version installed - so 'restart' your browser to get new cool
> feature' (FF normally already detects upgrades and suggest restart)
No, that’s not good enough. The OS should restart it for the user (other OSes
already can do this). (In the case of user-invisible components there is no
other option, and for user-visible GUIs it is also the right thing to do.)
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
