On 11. 4. 2014 at 17:08:49, Colin Walters wrote: > On Fri, Apr 11, 2014 at 1:05 PM, Miloslav Trmač <mitr@xxxxxxxx> wrote: > > So, having /usr/lib/passwd storing the same limited set of data is > > not the right long-term thing. Unfortunately, AFAIK the fuller > > interface isn't ready yet. > > Yeah, it'd be nice to merge the accountsservice database in to the > system db. (And in general, have more consolidation among > shadow-utils/sssd/accountsservice) > > > In the really-long-term, really-hand-wavy, future, I think we need to > > move away from the 32-bit UIDs[3], > > I agree: > http://www.redhat.com/archives/rhl-devel-list/2009-April/msg02456.html > > > [2] Overall I'm strongly convinced that the fully-stateless == > > fully-atomic-updates model is simply unworkable. We can have > > stateless/atomic software installation, but we absolutely do need to > > allow for arbitrary operations to be done on system's state between > > loading the new version on disk and starting it. Fedora-atomic can > > have special support for a few classes of state know in advance, but > > fully general software needs fully general post-installation > > adjustments. (E.g., where does ALTER TABLE ADD COLUMN on software > > upgrade fit in the Fedora-atomic model?) > > An ExecStartPre= entry in the systemd unit. I will play devil's advocate here: 1) What if I don't use systemd to start whatever program needs the updated data? (might not be a daemon for example) 2) Wouldn't that start the migration script every time the daemon starts? Doesn't sound like a pretty solution. Thanks Jan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
