On May 19, 2010, at 2:26 PM, Denis Washington wrote: > >> Meanwhile, what you are describing (and guessing from your previous >> freedesktop-like >> implementation), you might as well just use PackageKit, which already has >> backends >> and more. >> > > Interesting how often my proposal was directly compared to PackageKit > (including PackageKit author Richard Hughes himself) just because of the > choice of technologies. >
Fear not: I'm hardly confusing your previous "Bergdorf API" implementation with PackageKit (which I think is a bit silly as tools go). However, you _DID_ choose certain technologies from GNOME freedesktop for your "Bergdorf API", and the largest objections (not from me) were that you had used GNOME freedesktop API's prematurely/incorrectly. (All from memory, I'll dig out details for my delusions if necessary; I'm certainly not disagreeing/arguing what you are/were trying to do or did, I'm an innocent bystander here ;-). > PackageKit is designed as an interface for installing distro-specific > packages or getting specific packages from distro-specific package > repositories. That's its use case. Registring software in the package > manager's database that does *not* come in the form of a native distro > package is completely outside of that use case. Adding that to PackageKit > would not make much sense imho. Also, PackageKit is not used in many distros > (only in RHEL probably) so it is by far not a candidate for inclusion into > the LSB. > No need to explain: PackageKit is silly/foolish as tools go. JMHO, YMMV, everyone's does. > Also, I am aiming for a more low-tech implementation this time. As the > fallback implementation must work without being installed on the system, > things like registered D-BUS services and PolicyKit are a no-no anyway. A > simple library depending only on libc (and glib, if I'm lazy, plus the > package-manager-specific libraries used in the backends) will most probably > do, assuming the installer will run as root (which is no worse than existing > ISV installers). > Are you writing an "ISV installer"? A "standard" specification? Resurrecting the "Bergdorf API"? All or some or any of the above? I cannot yet tell ... meanwhile the "Bergdorf API" got farther along than any other implementation, so please -- no need to apologize for anything. >>> - In parallel, fill the holes in the LSB RPM spec (possibly uplifting to >>> v4) and try to synchronize the metadata semantics with the ones of the >>> package API (meaning, probably, that the package API will end up receiving >>> RPM semantics at many places). This means we will have the package API for >>> things like cross-platform installers on the one side and the RPM format as >>> an alternative direct format on the other side, and we may be able to keep >>> compatibility with the old RPM spec. (Crucial as the LSB 4.x series is >>> committed to backwards compatibility.) >>> >>> >> Please, its the "LSB format" spec, not the "LSB RPM spec". >> >> The distinction is crucially important. >> >> What LSB has chosen to make "standard" has nothing to do with RPM for >> many years now. >> >> > > As you please. > (aside) I've wasted months of my life on the confusion between LSB <-> RPM. Enuf: LSB != RPM. Period. They are different implementations and different "branding". If you want a "LSB package" installer/format/brand/whatever, well its silly to talk on an RPM list for a LSB "product" and/or "standard". >>> There are probably a lot of issues with this path, but it might be a good >>> start to experiment with. What do you think? >>> >>> >> For register/unregister (and "transactionally protected" ACID behavior), I'm >> currently embedding sqlite3 in RPM, and using sqlite3 "virtual tables" (VT) >> as >> an abstraction for register/unregister (largely because sqlite3 VT have two >> phase commit methods), and using SQL as a data focussed implementation >> language. >> >> Note "data focussed" and de facto bog-standard as the basis for choosing SQL. >> I don't particularly like SQL or sqlite3 implementation languages. >> > > Unfortunately I don't understand what exactly you are trying to do. Could you > elaborate a bit on this? > I'm looking for "package" register/unregister methods (a la the "Berlin API") implemented directly in SQL. All the rest of what I said are implementation details. 73 de Jeff ______________________________________________________________________ RPM Package Manager http://rpm5.org LSB Communication List rpm-lsb@rpm5.org
