Hi, I just synced my portage tree, and when running the classical emerge -DuNa @world, I ran in the following: emerge: there are no ebuilds built with USE flags to satisfy "dev-db/sqlite[threadsafe,-secure-delete]". !!! One of the following packages is required to complete your request: - dev-db/sqlite-3.7.3 (Change USE: -secure-delete) (dependency required by "net-irc/quassel-0.7.1" [installed]) (dependency required by "@selected") (dependency required by "@world" [argument]) But net-libs/xulrunner requires dev-db/sqlite to be compiled with USE=secure-delete (for obvious security reasons). AFAIK, the fact sqlite is compiled with secure-delete does not enforce apps depending on sqlite to suffer from it, if they don't explicitly request this feature... Can scarabeus be more precise about the change 1.5 in the bug URL? Thanks
net-libs/xulrunner only requires dev-db/sqlite to be compiled with USE=secure-delete if you use system-sqlite
(In reply to comment #1) > net-libs/xulrunner only requires dev-db/sqlite to be compiled with > USE=secure-delete if you use system-sqlite > You're right, I edited the summary to reflect this fact.
Now also affects www-client/chromium with USE="system-sqlite"
Created attachment 269343 [details] Quassel ebuild without -secure-delete on sqlite Just tested the attached ebuild after re-emerging sqlite with secure-delete and quassel as well. Both client and core seem to work on a quick test, any other things to try?
Damn i thought i already replied to this. Within sqlite there is switch that makes all deletes really secure but damn slow, by slow i mean that all the operations are at ~10-30% of its speed. This switch can be enabled on runtime, but some crazy upstreams decided that sqlite must be secure always so thus there is secure-delete useflag. If it is enabled it enforces the feature every time making it slow all the time. Now as you can see your client/server will work, but it will be shit-ass slow on quite few operations. I really don't plan or want to fix this (you still can use non-system sqlite by those packages or better persuade the upstream to stop being stupid and use runtime options when they are availible).
(In reply to comment #5) > Damn i thought i already replied to this. > > Within sqlite there is switch that makes all deletes really secure but damn > slow, by slow i mean that all the operations are at ~10-30% of its speed. > > This switch can be enabled on runtime, but some crazy upstreams decided that > sqlite must be secure always so thus there is secure-delete useflag. If it is > enabled it enforces the feature every time making it slow all the time. > > Now as you can see your client/server will work, but it will be shit-ass slow > on quite few operations. > > I really don't plan or want to fix this (you still can use non-system sqlite by > those packages or better persuade the upstream to stop being stupid and use > runtime options when they are availible). Okay, thanks for clearing that up. Should have realized this, I've come across it before.
Tomáš, can you please reopen and fix this? I have been using Quassel for a few weeks with secure-delete enabled and it works very well for me. You can always add an ewarn if you really feel that it is necessary. A dependency is too harsh.
In my humble opinion, the correct solution would be to make secure deletion in dev-db/sqlite an option at run-time rather than at compile-time. This would make it possible to enable/disable secure deletion on a per-ebuild basis, or indeed at run-time.
(In reply to comment #8) > In my humble opinion, the correct solution would be to make secure deletion in > dev-db/sqlite an option at run-time rather than at compile-time. This would > make it possible to enable/disable secure deletion on a per-ebuild basis, or > indeed at run-time. There is a way to change it at run-time (PRAGMA secure_delete), the problem is that Firefox upstream refuses to do it at run-time and instead insists that SQLite must default to secure-delete=true, to save on their typing. So, because Firefox doesn't want to request non-standard behavior at run-time, everyone else is forced to request standard behavior at run-time. Anyway, this has been discussed at length before, both here and at Mozilla, and is not likely to change anytime soon. The only thing I'm asking here is that we don't make a bad situation worse. I'd rather take the performance hit than use FF's bundled libs, and anyone who sets USE=secure-delete probably feels the same.
(In reply to comment #9) > There is a way to change it at run-time (PRAGMA secure_delete), the problem is > that Firefox upstream refuses to do it at run-time and instead insists that > SQLite must default to secure-delete=true, to save on their typing. > > So, because Firefox doesn't want to request non-standard behavior at run-time, > everyone else is forced to request standard behavior at run-time. > > Anyway, this has been discussed at length before, both here and at Mozilla, and > is not likely to change anytime soon. The only thing I'm asking here is that we > don't make a bad situation worse. I'd rather take the performance hit than use > FF's bundled libs, and anyone who sets USE=secure-delete probably feels the > same. I'd trust the sqlite developers on this matter. According to http://www.sqlite.org/compile.html they default to not using secure-delete. And for good reasons, I suppose. I believe the right thing to do were to patch Firefox/Icecat regardless of upstream being cocky on this matter. It is rather evident that they would only benefit from the performance gain of using PRAGMA secure_delete at runtime where needed. Does Gentoo even need Mozilla's permission for this or are we dealing with Free Software here?
(In reply to comment #10) > I believe the right thing to do were to patch Firefox/Icecat regardless of > upstream being cocky on this matter. The Mozilla herd doesn't want to do it. See bug 304913.
So, I understand why the secure-delete implementation in sqlite is dumb. What I don't understand is why it is a dependency for quassel. Yes, it doesn't work as well with it enabled. Neither does any other package that depends on sqlite. This really seems to me like a valid bug. By all means ewarn if it has an unusually significant impact on sqlite, or just einfo to point it out in case the user set it inadvertently. However, it should not be a blocker for installation.
(In reply to comment #12) > So, I understand why the secure-delete implementation in sqlite is dumb. > > What I don't understand is why it is a dependency for quassel. Yes, it > doesn't work as well with it enabled. Neither does any other package that > depends on sqlite. > > This really seems to me like a valid bug. By all means ewarn if it has an > unusually significant impact on sqlite, or just einfo to point it out in > case the user set it inadvertently. However, it should not be a blocker for > installation. Dunno if word TOO slow is not for you. But simply it is not working well with it enabled. Yes it will install but produce various runtime issues, so it is up to you to deal with the problems yourself. Problem is on mozilla side not here. THe secure-delete should never be useflagged as it is brainead idea.
(In reply to comment #13) > Dunno if word TOO slow is not for you. But simply it is not working well > with it enabled. Yes it will install but produce various runtime issues, so > it is up to you to deal with the problems yourself. Problem is on mozilla > side not here. THe secure-delete should never be useflagged as it is > brainead idea. I'll agree that it is a braindead idea. I just checked and it seems like the packages I was aware of which required it to be set are gone now, so this might be moot. If it ever becomes non-moot it might be worth some thought, but no sense debating hypotheticals.
*** Bug 551018 has been marked as a duplicate of this bug. ***
I don't use this anymore but... (In reply to Tomáš Chvátal from comment #13) > Dunno if word TOO slow is not for you. But simply it is not working well with it enabled. It was not too slow for me. It worked well with it enabled. It should be obvious, but whether it is too slow or not is completely dependent on hardware, usage and expectations, like pretty much every other program. > Problem is on mozilla side not here. There is a problem on the Mozilla side, and there is a different, completely artificial problem here that you created all by yourself. > THe secure-delete should never be useflagged as it is brainead idea. So is making Quassel depend on -secure-delete.
