Re: [Evolution-hackers] XDG Base Directories
On Sat, 2010-10-16 at 11:49 -0400, Martin Owens wrote: > > * Cached Camel provider data moves to ~/.cache/evolution/mail. This > > includes folders.db. Files for local accounts will be divided up: > > index files for searching would go in ~/.cache, whereas actual mail > > content (mbox/Maildir/etc.) would go in ~/.local. Need to think on > > that some more. > > You do know that ~/.local is for user application data and not > application user data? Yes they sound almost like the same thing, but > there is a very big difference between firefox plugins/evolution filters > and emails/calendar events. > > Because hiding user data is cool and making backups impossible is > awesome. > > If you're planning on separating out the indexing (a good move) then why > not just park emails in ~/Documents/Email in a list of maildirs? My examples above were mistaken. I was referring to account types that deliver mail to the "On This Computer" store such as POP. How and where those mails get stored is up to Evolution. You can still set up ~/Documents/Email as the root of a maildir tree and point Evolution at it. The data there won't be moved. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories
Hey Matthew, I welcome the move to XDG at last but... On Sun, 2010-06-06 at 12:34 -0400, Matthew Barnes wrote: > .local/ > +-- share/ > +-- evolution/ > +-- addressbook/ > | +-- <> > +-- calendar/ > | +-- <> > +-- mail/ > | +-- <> > +-- memos/ > | +-- <> > +-- tasks/ > | +-- <> > +-- camel-cert.db > +-- cert8.db > +-- cert9.db > +-- key3.db > +-- key4.db > +-- mapi-profiles.ldb > +-- secmod.db > > > Comments: > > * Cached Camel provider data moves to ~/.cache/evolution/mail. This > includes folders.db. Files for local accounts will be divided up: > index files for searching would go in ~/.cache, whereas actual mail > content (mbox/Maildir/etc.) would go in ~/.local. Need to think on > that some more. You do know that ~/.local is for user application data and not application user data? Yes they sound almost like the same thing, but there is a very big difference between firefox plugins/evolution filters and emails/calendar events. Because hiding user data is cool and making backups impossible is awesome. If you're planning on separating out the indexing (a good move) then why not just park emails in ~/Documents/Email in a list of maildirs? Martin, ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories
Le dimanche 06 juin 2010 à 12:34 -0400, Matthew Barnes a écrit : > Once thing I'd like to get done before Evolution 3.0 is dismantling > ~/.evolution and moving user-specific data to relocatable XDG base > directories [1]. I have an initial proposal of what should go where. > > Migration should just be a series of straight-forward move commands, > plus a few subtle renames. Not sure yet if I'm gonna code this all up > in C or just write a shell script to invoke. > > I'd like to get this in before I get much further on my gsettings > branch, as I'll be changing how we store account data (no more XML > blobs!) and our directory layout closely ties into it. > > See additional comments below. [...] > Comments: > > * ~/.evolution/cache moves to ~/.cache/evolution, with one exception: > just use /tmp for stuff that normally goes in ~/.evolution/cache/tmp. > > * Cached Camel provider data moves to ~/.cache/evolution/mail. This > includes folders.db. Files for local accounts will be divided up: > index files for searching would go in ~/.cache, whereas actual mail > content (mbox/Maildir/etc.) would go in ~/.local. Need to think on > that some more. > > * ~/.cache/evolution/http will eventually die when we move to WebKit, > since it uses (or will soon use) its own disk cache. > > * ~/.evolution/$COMP/local moves to ~/.local/share/evolution/$COMP. > > * I debated whether certificate and profile databases are data files or > configuration files. I decided data files, based on my rule of thumb > that configuration files should be human-readable. > > > Any comments or concerns? Have I missed anything? > sounds good. I"d like to mention again that it would be nice if evolution could take into account system certificates as a basis for user trust settings in certificate signatures, etc. I don't know if nss is just getting in the way for this, but evolution and firefox are currently the two apps that I use most often that don't actually obey my system configuration by default. -- Gilles Dartiguelongue ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On Sun, 2010-07-25 at 19:23 -0400, Matthew Barnes wrote:
> On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote:
> > I now have all the migration routines written and I'm fairly happy with
> > them. A few more cases to test and I think I may commit this over the
> > weekend.
>
> I decided to defer this until at least Tuesday, so that those developers
> who aren't weekend workaholics like me still have some advance warning
> when they fire up their email on Monday morning.
The base directory transition is now in master.
Once again, please be mindful not to mix versions of Evolution and the
addressbook and calendar factory daemons.
The migration should be nearly instantaneous. It's just a series of
directory renames and a few config file renames. Each of the three
binaries will print equivalent UNIX shell commands ("mv" and "rmdir") to
the terminal along with any errors encountered to help track migration
progress. This output is valuable for debugging migration issues.
Please let me know immediately if you encounter any regressions. If
there -are- regressions I expect they will be caused by Evolution not
finding some data, either because the data failed to migrate or because
Evolution is still looking for migrated data in its old home. In either
case the data should still be present on your hard disk.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On Tue, 2010-07-27 at 08:24 +0200, Milan Crha wrote: > does this mean that one would be able to keep .evolution folder as is, > with some XDG foo? You know, sometimes is useful to run 2.30.x while > developing 2.31.x on the same machine, where your change makes it > impossible. > > But if it's possible, do you know the XDG foo to achieve it? It's not possible to set the XDG environment variables to mimic Evolution's existing directory layout. I suppose you could try playing games with soft links, but I won't recommend anything like that. Easiest approach I can think of is to rename your ~/.evolution directory to something else before running 2.31.6 or later (that goes for both Evo and the D-Bus services). That will prevent migration from occurring. Then rename it back to ~/.evolution before running 2.30.x. I haven't tried this myself, but I anticipate you'll notice some UI state missing the first time you run 2.31.6 and it will have to recreate all your cached data, but your user preferences and account settings in GConf should carry over. You -will- however get the duplicate local ESource glitch, since both 2.30.x and 2.31.6 will still be writing to the same GConf keys. So just be aware of that. Once we have both stable and unstable versions compliant with the XDG base directory spec, this will get a lot easier to manage. You'll be able to set up as many separate Evolution profiles as you want in the same user account, making it much easier to test things like first time setup experience or meeting negotiations between multiple "users", all without harming your normal working profile. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote: > For those following the master branch of git, that means that with any > luck your ~/.evolution directory will soon be gone and you'll have far > more control over where Evolution writes files. Hi, does this mean that one would be able to keep .evolution folder as is, with some XDG foo? You know, sometimes is useful to run 2.30.x while developing 2.31.x on the same machine, where your change makes it impossible. But if it's possible, do you know the XDG foo to achieve it? Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote: > I now have all the migration routines written and I'm fairly happy with > them. A few more cases to test and I think I may commit this over the > weekend. I decided to defer this until at least Tuesday, so that those developers who aren't weekend workaholics like me still have some advance warning when they fire up their email on Monday morning. Also, I plan to merge one of Srini's branches tonight with some exciting new features for Express mode. That's gonna kick up some dust that will need to settle before I drop the next bombshell. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
Heya :-) On 24.07.2010 13:16, Matthew Barnes wrote: > Are you suggesting we copy the data instead of moving it? That could be > a -lot- of data. Hm. You could probably hardlink it. Cheers, Tobi signature.asc Description: OpenPGP digital signature ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On Sat, 2010-07-24 at 07:48 +0200, Yves-Alexis Perez wrote: > An an evolution user and a packager, is this really a good idea? > Shouldn't it be safer to keep it “as a backup” but mark it as already > migrated. This way, another attempt can be tried should the first one > fail, and we don't touch user valuable data. Are you suggesting we copy the data instead of moving it? That could be a -lot- of data. It also runs a higher risk of failure since the user's hard drive may not have enough free space for a copy. The migration at present is just a scripted sequence of rename() and rmdir() commands. The problem is we have three binaries writing data there. Two of those have no user interface, and may start long before you launch Evolution itself. So the migration needs to happen in phases, and I don't see a way to warn the user ahead of time. By the time you start Evolution, the data may already be 2/3 migrated by the D-Bus services. That said, I'm open to ideas for making the process safer. Especially for the case where the user tries to downgrade and then panics because Evolution suddenly can't find his data. Should Evolution present a big scary warning at startup if it sees (from GConf) that a later version was previously run? ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On ven., 2010-07-23 at 18:08 -0400, Matthew Barnes wrote: > * Don't downgrade! Once you cross this threshold, it's going to > be > fairly painful to revert data files back to a state that > earlier > Evolution versions can understand. > > Each of the three binaries -- evolution, e-addressbook-factory, and > e-calendar-factory -- migrates its own data and then tries to remove > ~/.evolution, which only works if the directory is empty. The idea is > whichever program starts last should succeed. > An an evolution user and a packager, is this really a good idea? Shouldn't it be safer to keep it “as a backup” but mark it as already migrated. This way, another attempt can be tried should the first one fail, and we don't touch user valuable data. We already saw weird bugs with data loss during the sqlite migration, so I have to admit I'm a bit scared at this point :) Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On Sun, 2010-06-06 at 12:34 -0400, Matthew Barnes wrote: > Once thing I'd like to get done before Evolution 3.0 is dismantling > ~/.evolution and moving user-specific data to relocatable XDG base > directories [1]. ... > [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html I now have all the migration routines written and I'm fairly happy with them. A few more cases to test and I think I may commit this over the weekend. For those following the master branch of git, that means that with any luck your ~/.evolution directory will soon be gone and you'll have far more control over where Evolution writes files. To keep your Evolution build running smoothly through this transition, it's important to heed a few warnings. * Keep your git repos up-to-date and make sure you're running the latest revisions of evolution-data-server, evolution, and the exchange/mapi packages if you use them. * Make sure your newly built e-addressbook-factory program is running and successfully acquires its D-Bus interface name: "org.gnome.evolution.dataserver.AddressBook" * Same goes for e-calendar-factory. Its interface name is: "org.gnome.evolution.dataserver.Calendar" * Don't downgrade! Once you cross this threshold, it's going to be fairly painful to revert data files back to a state that earlier Evolution versions can understand. Each of the three binaries -- evolution, e-addressbook-factory, and e-calendar-factory -- migrates its own data and then tries to remove ~/.evolution, which only works if the directory is empty. The idea is whichever program starts last should succeed. If all goes smooth, once all three programs are up and running, your ~/.evolution directory will be gone and the files will be partitioned into three base directories which are by default: ~/.local/share/evolutionThe user's data files. ~/.config/evolution Various configuration and state files. ~/.cache/evolution Disposable data caches. If after the migration is complete you find you still have files under ~/.evolution, I'd like to know about it. I plan to spend the next few weeks chasing corner cases and tweaking the migration routines so it's as robust as possible by 3.0. Let me know how it goes. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
