As I mentioned in a comment to bug 249418, dev-db/sqlite-2 is an important tool in its own right, not just as a library dependency for other packages. Current versions of sqlite cannot open version 2 databases, and those of us who have to work with those databases for various reasons (e.g. interacting with 3rd-party software or platforms that only support v2 databases) now have no way to open or edit them using tools in the Portage tree. Even the common recommendation of "convert your sqlite2 databases to sqlite3 format" cannot be done without a sqlite 2 binary. Please restore the sqlite2 ebuild or provide a compatible tool to edit sqlite2 databases.
This is all very well but Arfrever cannot off his own 'bat' since he does not have access to 'the tree'. I am not sure where this request can go.
I never touched ebuilds of SQLite 2. I doubt that anybody is interested in maintaining SQLite 2. You can add ebuild of SQLite 2 to your local private repository.
And where precisely are we supposed to get that ebuild now? See, there used to be one in the Portage tree, and it compiled cleanly and worked great. It's not there anymore. Considering that this ebuild didn't actually need any maintenance (there haven't been any new upstream releases since 2005) what exactly are the requirements for an ebuild to stay in the Portage tree? What's the next tool that gets removed from Gentoo because some particular dev doesn't have a need for it?
(In reply to Dani Church from comment #3) > And where precisely are we supposed to get that ebuild now? https://gitweb.gentoo.org/repo/gentoo.git/log/dev-db/sqlite Click commit directly before deletion of given file (in this case commit before "dev-db/sqlite: Drop masked for removal version (#249418)". On this page click "tree" button. On this page click given file and next "plain" button, or directly "plain" button for given file.
(In reply to Dani Church from comment #3) > And where precisely are we supposed to get that ebuild now? > > See, there used to be one in the Portage tree, and it compiled cleanly and > worked great. It's not there anymore. > > Considering that this ebuild didn't actually need any maintenance (there > haven't been any new upstream releases since 2005) what exactly are the > requirements for an ebuild to stay in the Portage tree? What's the next > tool that gets removed from Gentoo because some particular dev doesn't have > a need for it? It is normal procedure to purge old ebuilds and versions. Your wish for this to be preserved is likely the rare exception, and Arfrever has obliged you with a full set of instructions to re-acquire it.
(In reply to Ian Delaney from comment #5) > It is normal procedure to purge old ebuilds and versions. Your wish for > this to be preserved is likely the rare exception, and Arfrever has obliged > you with a full set of instructions to re-acquire it. It's also normal procedure to keep the latest version of any given SLOT around, especially for packages where upstream compatibility is minimal or nonexistent between versions. Take, for example, automake/autoconf, where we keep legacy versions dating back to 1999 in the tree, because projects designed to build with one version will not reliably do so with another. Or, for an even closer example, sys-libs/db-1.85, which was released upstream in 1994 and is "kept around for really old packages". I wouldn't be complaining if this were just a version bump issue, and it isn't even just that packages written against sqlite-2 won't compile against sqlite-3. My biggest issue, as I've mentioned, is that there is now no tool in the tree that can parse or interact with the sqlite2 file format. This means that when I set up a new workstation and I need to tweak or even view a sqlite2 database, I can't just emerge -av sqlite:2. Now, I have to: 1. Open a web browser, find the Gentoo portage repository online. (Emerge a web browser first, if this is a particularly new workstation.) 2. Navigate to the dev-db/sqlite directory. 3. Comb through the logs to find where the sqlite 2 ebuild was deleted. 4. Download the old ebuild, as well as all the supporting patches etc from files/. 5. Set up a portage overlay, if I haven't done that yet. Probably look up the docs to see what files are required for that these days, since it isn't as easy as just setting PORTDIR_OVERLAY anymore. 6. Slot the ebuild and files into their proper places in the overlay. 7. ebuild sqlite-2*ebuild digest. 8. emerge -av sqlite:2. I mean, I'll do it. Obviously I have to, since you don't appear to have any intention of restoring the ebuild to the tree. But if you want to know why I sound upset about this change, well, there's your STR.
@Dani: Would it be okay with you if I add it to my overlay? Then you could just use layman and emerge to install it on your systems.
