Re: The state of LSB Packaging?
On May 20, 2010, at 10:28 AM, Denis Washington wrote: > > Simple in that > > 1. it only consists of a very small set of C functions (essentially > register+unregister, plus a few to assemble the package metadata) which don't > require any other library to be used > Well, here's the existing (and SIMPLE) register/unregister API in RPM stripped to a bare-bones invocation: rpmdb db = ...; /* database handle */ Header h = ...; /* package metadata encapsulation */ uint32_t hdrNum = ...; /* package instance # in database. */ int rc = rpmdbAdd(db, time(NULL), Header h, NULL); int rc = rpmdbRemove(db, time(NULL), hdrNum, NULL); The only complexity there is in finding the API gozzintas, the API itself is already SIMPLE. I only mention to underscore Yet Again that is the data and context, not the API, that aren't SIMPLE. I wouldn't even discuss the register/unregister API per se, because its the data and the context, not the methods, that isn't SIMPLE. > >> But if you can devise some reasonable spewage for encapsulating "package" >> data, I'll try to embed your API @rpm5.org. >> > > Great to hear. > Just to try to be optimistic: Show me some code and I'll try to use it. 73 de Jeff __ RPM Package Managerhttp://rpm5.org LSB Communication Listrpm-lsb@rpm5.org
Re: The state of LSB Packaging?
Am 20.05.2010 14:58, schrieb Jeff Johnson: On May 20, 2010, at 4:03 AM, Denis Washington wrote: On May 19, 2010, at 10:12 PM, Jeff Johnson wrote: 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. Sorry for not being clear enough, let me explain again. There are only two things I am proposing for the LSB: - A sufficiently precise definition of a package and it's accompanying metadata. THis ounds like Yet Another Form of Markup Spewage. The definition of the metadata contents is nowhere near as important as the definition of the semantic interpretation of the content, or figuring how the spewage can be parsed into existing package managers when written in perl/python/ruby/java/ocaml/haskell/... etc. Again, Mancoosi and Nix are closest to getting the semantic interpretation precisely defined. OTOH, neither OCAML or C++/perl are very useful for say, a java/ruby/python package manager implementation. Both CUDF and Nix were a rather painful amount of effort to embed @rpm5.org in C (and neither of the implementations is very pleasing as code goes, or useful to RPM functionality, so far). I am well aware that the exact interpretation of the provided metadata is central to the specification. Please, remember that I am currently just presenting my general ideas, not a detailed definition of everything that is needed. - A VERY simple API for notifying the system package manager of the installation / removal of such a package. But what is the criteria for SIMPLE? Few methods with minimal arguments? Fewest prerequisites (like perl/OCAML)? Smallest resource usage? Most widely portable/available? Most distros/lusers who claim SIMPLE? Its reliability that is usually more important criteria after design/development (where SIMPLE is desirable because easiest to implement). ... Simple in that 1. it only consists of a very small set of C functions (essentially register+unregister, plus a few to assemble the package metadata) which don't require any other library to be used 2. its "fallback implementation" will be written in standard C + libc for maximum portability between Linux distributions (plus maybe package manager specific libraries for the fallback mechanisms, but those are only loaded if needed) 3. it is, because of the two properties above, _very_ simple to use from different programming languages (almost any programming language used in the real world can reasonably well interface with C). Primarily I meant the first of these points: the interface should be very narrow and not take a lot of effort to implement for a given packaging system. (Provided the specified package semantics can be easily mapped to the semantics of the native packaging system.) Which might let the distro makers think: if no ISV will use the API anyway, is there any point in implementing it at all? The classic chicken-and-egg problem. These are the flaws with an approach through an API. Until the API exists and is widely deployed, noone will use the API no matter what functionality the API provides. ... That's the point of the fallback implementation: it allows ISVs to use the API *before* it is deployed by the distros, providing them a reasonable amount of integration when the implementation has a fallback, and no penalty (opposed to the current situation) when not. Using this fallback implementation, an ISV would have the instant benefit of increased integration with the native packaging system by using the API now. At worst, in the case of more exotic package systems without existing fallback (the ISV has probably not supported that before, anyway), the (un)installation process would be as badly integrated as before, so using the API would be win-only. Because of this, chances are that the API gets more widespread use, which in turn might get package managers to implement the spec, which in turn makes integration better because the fallback mechanisms don't have to be used, which in turn makes users happy, which in turn makes ISVs and distros happy... you get the idea. How does that sound? Well, I said up front An API (and a method based approach) isn't what is needed imho. What is needed is a focus on data and emantics and access patterns. I said as much to LSB when the "Berlin API" was first proposed. In the risk of repeating myself: I know. I very well know. But this doesn't change the fact that before anything else, there must be a way for ISV-provided installers to communicate with the package manager. Without that, all definitions of semantics have no practical relevance, so that is why I am mentioning the API as a way to provide that. Bu
Re: The state of LSB Packaging?
On May 20, 2010, at 5:03 AM, Dominique Dumont wrote: > On Thursday 20 May 2010 10:03:55 Denis Washington wrote: >> How does that sound? > > A bit like some ideas I have regarding packaging for ISV ;-) : > > http://wiki.debian.org/SummerOfCode2010/UniversalPackageForIsv > > I proposed this for Google Summer of code, but no student stepped up. > These ideas are not well fleshed out, and I don't have time to work on them > until probably 2011 (I'm mentoring another project regarding package config > upgrade). > Well if/when you get to this Dependency are not declared with native package names, but with functionality names (a bit like the generic names used by update-alternatives). poke me. Here's some historical context re "functionality names" and "translation" from RPM <-> LSB: LSB insists No dependencies except "Requires: LSB" are permitted. and RPM (and most package managers) rely on dependency assertions to assemble collections of packages to be installed reliably. So in order to have it both ways, @rpm5.org has carefully moved most of the automated dependency generation from static to install-time methods. I.e. the dependencies can be generated automatically from content while installing, not from explicit static markup contained in packages while building. The connection with your proposal is that a naming/namespace taxonomy based on "functionality" (e.g soname(LIBRARY) for ELF linkage as one easy to describe "functionality") is very much needed. Note that (imho) "functionality" needs to be objectively tied to some testable closure mechanism, not left to some mysterious and magical or implicit DWIM for package dependency assertions as in update-alternatives. Nothing wrong with update-alternatives "functional" names per se, just that the closure mechanism needs to be well defined too, such as whether DT_NEEDED is matched with a DT_SONAME for ELF linkage. 73 de Jeff __ RPM Package Managerhttp://rpm5.org LSB Communication Listrpm-lsb@rpm5.org
Re: The state of LSB Packaging?
On May 20, 2010, at 4:03 AM, Denis Washington wrote: > On May 19, 2010, at 10:12 PM, Jeff Johnson wrote: >> 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. >> > > Sorry for not being clear enough, let me explain again. There are only two > things I am proposing for the LSB: > > - A sufficiently precise definition of a package and it's accompanying > metadata. > THis ounds like Yet Another Form of Markup Spewage. The definition of the metadata contents is nowhere near as important as the definition of the semantic interpretation of the content, or figuring how the spewage can be parsed into existing package managers when written in perl/python/ruby/java/ocaml/haskell/... etc. Again, Mancoosi and Nix are closest to getting the semantic interpretation precisely defined. OTOH, neither OCAML or C++/perl are very useful for say, a java/ruby/python package manager implementation. Both CUDF and Nix were a rather painful amount of effort to embed @rpm5.org in C (and neither of the implementations is very pleasing as code goes, or useful to RPM functionality, so far). > - A VERY simple API for notifying the system package manager of the > installation / removal of such a package. > But what is the criteria for SIMPLE? Few methods with minimal arguments? Fewest prerequisites (like perl/OCAML)? Smallest resource usage? Most widely portable/available? Most distros/lusers who claim SIMPLE? Its reliability that is usually more important criteria after design/development (where SIMPLE is desirable because easiest to implement). ... > > Which might let the distro makers think: if no ISV will use the API anyway, > is there any point in implementing it at all? > > The classic chicken-and-egg problem. > These are the flaws with an approach through an API. Until the API exists and is widely deployed, noone will use the API no matter what functionality the API provides. ... > Using this fallback implementation, an ISV would have the instant benefit of > increased integration with the native packaging system by using the API now. > At worst, in the case of more exotic package systems without existing > fallback (the ISV has probably not supported that before, anyway), the > (un)installation process would be as badly integrated as before, so using the > API would be win-only. Because of this, chances are that the API gets more > widespread use, which in turn might get package managers to implement the > spec, which in turn makes integration better because the fallback mechanisms > don't have to be used, which in turn makes users happy, which in turn makes > ISVs and distros happy... you get the idea. > > How does that sound? > Well, I said up front An API (and a method based approach) isn't what is needed imho. What is needed is a focus on data and emantics and access patterns. I said as much to LSB when the "Berlin API" was first proposed. But if you can devise some reasonable spewage for encapsulating "package" data, I'll try to embed your API @rpm5.org. 73 de Jeff __ RPM Package Managerhttp://rpm5.org LSB Communication Listrpm-lsb@rpm5.org
Re: The state of LSB Packaging?
On Thursday 20 May 2010 10:03:55 Denis Washington wrote: > How does that sound? A bit like some ideas I have regarding packaging for ISV ;-) : http://wiki.debian.org/SummerOfCode2010/UniversalPackageForIsv I proposed this for Google Summer of code, but no student stepped up. These ideas are not well fleshed out, and I don't have time to work on them until probably 2011 (I'm mentoring another project regarding package config upgrade). Feel free to re-use what you want. Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont __ RPM Package Managerhttp://rpm5.org LSB Communication Listrpm-lsb@rpm5.org
Re: The state of LSB Packaging?
On May 20, 2010, at 11:03 AM, Dominique Dumont wrote: On Thursday 20 May 2010 10:03:55 Denis Washington wrote: How does that sound? A bit like some ideas I have regarding packaging for ISV ;-) : http://wiki.debian.org/SummerOfCode2010/UniversalPackageForIsv I proposed this for Google Summer of code, but no student stepped up. These ideas are not well fleshed out, and I don't have time to work on them until probably 2011 (I'm mentoring another project regarding package config upgrade). Feel free to re-use what you want. Thanks for the pointer. Looks interesting, although the problem of merely defining a format, as lined out in the wiki page you linked to, is that support for that must be in the distros, which is somewhat a show-stopper as I explained. However, it would probably be a good idea to define a package format after (if) the API is widely adopted, as a long-term solution. The obvious advantage of a specified format opposed to the API (which will have to always be there as an alternative, though, for cross-platform installers and the like) is that installing is more secure, as packages of that format would be verified and installed by the system with no dangerous third-party code running (provided only restricted scriptlets are allowed). The API, on the other hand, requires ISV-provided installer code which will most likely have to run as root (but that's the case with current installers not using the API, too). All in all, a package format would be good for the future, but in the short run I'll concentrate on an API + metadata definitiion approach. Regards, Denis Wahsington __ RPM Package Managerhttp://rpm5.org LSB Communication Listrpm-lsb@rpm5.org
Re: The state of LSB Packaging?
On May 19, 2010, at 10:12 PM, Jeff Johnson wrote: 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. Sorry for not being clear enough, let me explain again. There are only two things I am proposing for the LSB: - A sufficiently precise definition of a package and it's accompanying metadata. - A VERY simple API for notifying the system package manager of the installation / removal of such a package. Distributions would be encouraged to implement this API in their system package manager for third-party installers to use. Likewise, ISV's and cross-platform installer authors would be encouraged to use that API. So if an installer uses it, and the system's package manager supports it, the installed package is registered correctly in the native package database, and all is fine and dandy. So far, so good. Now here's the problem: no distro / package manager currently supports the API, naturally, because it is not something that already existed before. And because this is the LSB, it _must_ already exist in the current enterprise distros before it gets into the standard. So even if the API would be implemented NOW, we would have to wait about 2 to 4 years before even the major enterprise distros have adopted it, and another year or so before it is officially part of the standard. What would that mean for ISVs? Right: the API would be completely irrelevant. Naturally, they COULD modify their installers to use the API if available and the old way otherwise, but why bother if really no single LSB-certified enterprise distro has support for it? Even if adding support for the API was cheap as dirt, there just wouldn't be any point. Which might let the distro makers think: if no ISV will use the API anyway, is there any point in implementing it at all? The classic chicken-and-egg problem. Having realized this, it should be clear that there must be a transition path between "nobody implements / uses the API" and "(almost) everybody implements / uses the API". And this is where the code *I* am planning to write comes into play: an implementation of the API that can be used by installers NOW by statically linking to it. That implementation will: - query the system package manager for an implementation of the API, and use that if available. - will use an built-in fallback mechanism if the system package manager does NOT implement the API, provided the package manager is known to the fallback implementation. In the case of rpm, this would probably be similar to the rpmlib hackery I showed you with the Burgdorf API. - do nothing if there is neither a system nor a fallback implementation, that is, package (un)registration will be a no-op. Using this fallback implementation, an ISV would have the instant benefit of increased integration with the native packaging system by using the API now. At worst, in the case of more exotic package systems without existing fallback (the ISV has probably not supported that before, anyway), the (un)installation process would be as badly integrated as before, so using the API would be win-only. Because of this, chances are that the API gets more widespread use, which in turn might get package managers to implement the spec, which in turn makes integration better because the fallback mechanisms don't have to be used, which in turn makes users happy, which in turn makes ISVs and distros happy... you get the idea. How does that sound? Regards, Denis __ RPM Package Managerhttp://rpm5.org LSB Communication Listrpm-lsb@rpm5.org
Re: The state of LSB Packaging?
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 Managerhttp://rpm5.org LSB Communication Listrpm-lsb@rpm5.org
Re: The state of LSB Packaging?
Am 19.05.2010 19:24, schrieb Jeff Johnson: On May 19, 2010, at 5:57 AM, Denid Washington wrote: I'm still willing to help however I can with LSB+RPM. Its _INSANE_ to continue futile "Packaging War" battles and and no users benefit (but certainly distros/vendors benefit from de facto monopolies through customer lock-in using software packaging). Good to know, I would be thankful for any kind of help. Right now I am thinking hard about how an LSB packaging standard would have to look like. I still like the idea of a package-manager-agnostic packaging API, but I came to believe that a standard would have to be something that is actually implemented in current LSB-certified "enterprise" distros - I underestimated how unwilling the LSB seems to be to lead instead of just following. So for any packaging standard to come, it is clear that it must work without any distro-side modifications. The question is how this requirement meshes with the package API idea. Currently, I am thinking of the following: The logic flaw here is attempting a method based API approach. If you want an "API", you have two choices: 1) Write your own API. 2) Trick someone else into writing your API. LSB was very much about 2) not 1) and they failed to trick anyone. (aside) What should be done first is to get workable concepts for fundamentals like "package" and "upgrade". Sure you can start with simple abstractions like A "package" has a "name" and a "version" concatenated in a string. but there's a whole lot more that needs to be done in the "real world". I know. As I stated, the metadata needs to be defined as precisely as possible. As I am only roughly sketching a rough plan how to proceed, I haven't got into the details yet, but yes, that is the single most important thing that a future LSB packaging standard must specify. Note that the fundamental flaw with "LSB packages" and the "LSB package format" is that LSB hoped to piggy back on a de facto existing implementation called RPM. LSB has _NEVER_ attempted anything but attempting to ram home a "standard" for RPM packaging. And again, they've failed to "trick" anyone with the "LSB packaging standard". There are in fact no LSB "standard" packages because the "standard" describes a "LSB format" that is no longer widely used by any RPM implementation. I realize that. What follow are some suggestions. I'll assume that you will eventually figger well defined meanings for "package" and "upgrade" and other absolutely essential data items. So do I. - Design an implementation with backends for different package systems as started before, but with the difference that the implementation does _not_ need to be installed on the distro, but can be linked into an ISV's installer. In the case of RPM, this could be done with librpm. (Probably the pre-4.6 "legacy" RPMv4 API, as that should be what all RPM-based LSB distros support.) For other package managers like dpkg, which don't have a public library, packages would have to be created on-the-fly and installed, much like some installers currently do as well (the ATI binary driver installer comes to mind). If you want different backends, you end-up getting into implementations and APIS where you need to "trick" up implementations in order to proceed. See how LSB failed, and don't make the same mistake. The whole backend architecture is explicitly thought as an intermediate solution. Distributions are encouraged to implement that interface cleanly in their package managers, thus avoiding any "tricks" / hacks. But for the API to work *now*, we need a fallback implementation that can be shipped with installers and does the job on today's distros, even if maybe somewhat hacky. That said, the approach *is* problematic. But I fear that, if the proposal won't work on the current LSB-certified distros, it will be turned down real fast. And, the fallback implementation would naturally use the "clean native" implementation of the system's package manager if it is enable, so the fallback solution will only be used on "legacy" distributions. 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. 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 prob
Re: The state of LSB Packaging?
On May 19, 2010, at 5:57 AM, Denid Washington wrote: >> >> I'm still willing to help however I can with LSB+RPM. Its _INSANE_ to >> continue >> futile "Packaging War" battles and and no users benefit (but certainly >> distros/vendors benefit from de facto monopolies through customer >> lock-in using software packaging). >> > > Good to know, I would be thankful for any kind of help. Right now I am > thinking hard about how an LSB packaging standard would have to look like. I > still like the idea of a package-manager-agnostic packaging API, but I came > to believe that a standard would have to be something that is actually > implemented in current LSB-certified "enterprise" distros - I underestimated > how unwilling the LSB seems to be to lead instead of just following. So for > any packaging standard to come, it is clear that it must work without any > distro-side modifications. > > The question is how this requirement meshes with the package API idea. > Currently, I am thinking of the following: > The logic flaw here is attempting a method based API approach. If you want an "API", you have two choices: 1) Write your own API. 2) Trick someone else into writing your API. LSB was very much about 2) not 1) and they failed to trick anyone. (aside) What should be done first is to get workable concepts for fundamentals like "package" and "upgrade". Sure you can start with simple abstractions like A "package" has a "name" and a "version" concatenated in a string. but there's a whole lot more that needs to be done in the "real world". Note that the fundamental flaw with "LSB packages" and the "LSB package format" is that LSB hoped to piggy back on a de facto existing implementation called RPM. LSB has _NEVER_ attempted anything but attempting to ram home a "standard" for RPM packaging. And again, they've failed to "trick" anyone with the "LSB packaging standard". There are in fact no LSB "standard" packages because the "standard" describes a "LSB format" that is no longer widely used by any RPM implementation. What follow are some suggestions. I'll assume that you will eventually figger well defined meanings for "package" and "upgrade" and other absolutely essential data items. > - Define the package API essentially as discussed before, with simple > register/unregister methods, plus precisely defined package metadata. > Nothing wrong with register/unregister methods. And "precisely defined" is on the right track, register/unregister certainly need markup spewage that is parseable, or other gozzintas/comesoutas. (aside) Look carefully at CUDF from http://mancoosi.org. There are some flaws, like Version: is typed as an INT (versions in the real world are far more complicated), but everything else is quite carefully defined, including "package" and "upgrade". > - Design an implementation with backends for different package systems as > started before, but with the difference that the implementation does _not_ > need to be installed on the distro, but can be linked into an ISV's > installer. In the case of RPM, this could be done with librpm. (Probably the > pre-4.6 "legacy" RPMv4 API, as that should be what all RPM-based LSB distros > support.) For other package managers like dpkg, which don't have a public > library, packages would have to be created on-the-fly and installed, much > like some installers currently do as well (the ATI binary driver installer > comes to mind). > If you want different backends, you end-up getting into implementations and APIS where you need to "trick" up implementations in order to proceed. See how LSB failed, and don't make the same mistake. 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. > - 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. > 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 sqli
Re: The state of LSB Packaging?
On May 18, 2010, at 7:20 PM, Jeff Johnson wrote: On May 18, 2010, at 12:27 PM, Denid Washington wrote: Hi, You might remember me - I'm the one who wrote a sketchy implementation of the then-discussed "Berlin Packaging API" about two years ago [1]. I have shifted my focus to other things since then, but since recently have more time again and my interest on the topic has been sparked again. Certainly I remember you. Great to hear. :) Now I am trying to gather what has happened since then. If I haven't missed anything, there was not that much to be missed. The packaging list archives seem to be effectively dead. The only thing I found was thoughts about uplifting to RPMv4 sprinkled around some LSB Wiki pages, for instance the LSB 4.1 Project Plan [2]. Yep. Nothing whatsoever to be missed. The last dialogue I was involved in was (~12/2008): Q: What is the _ONE_ most important item for the LSB 4+ packaging standard? A: Establishing a "standard" version comparison so that "newer" and "upgrade" are well defined. Nothing heard (by me) since. Unfortunate, but I thought as much. Now, because I remembered you, Jeff Johnson, to be very constructive, honest and generally helpful in criticizing my proposal (and always entertaining) and were very much involved in the whole discussion, I would like to ask you: what is the state of discussion regarding LSB packaging? Do you know about any progress on this front since, say, the end of 2008? Any hints would be very valuable for me, as I am seriously thinking about a second (maybe more coordinated, complete and consensus-reaching) attempt at working on a new LSB packaging proposal.. LSB packaging is as extinct as the Dodo AFAIK. (aside) You might want to look at http://mancoosi.org which is closest (but "research" not "standard", standards are much harder) to evolving something better for software packaging. Will do so. There's also http://nixos.org which is attempting "functional" packaging that avoids many of the snarly issues presented by "standard" packaging. I'm still willing to help however I can with LSB+RPM. Its _INSANE_ to continue futile "Packaging War" battles and and no users benefit (but certainly distros/vendors benefit from de facto monopolies through customer lock-in using software packaging). Good to know, I would be thankful for any kind of help. Right now I am thinking hard about how an LSB packaging standard would have to look like. I still like the idea of a package-manager-agnostic packaging API, but I came to believe that a standard would have to be something that is actually implemented in current LSB-certified "enterprise" distros - I underestimated how unwilling the LSB seems to be to lead instead of just following. So for any packaging standard to come, it is clear that it must work without any distro-side modifications. The question is how this requirement meshes with the package API idea. Currently, I am thinking of the following: - Define the package API essentially as discussed before, with simple register/unregister methods, plus precisely defined package metadata. - Design an implementation with backends for different package systems as started before, but with the difference that the implementation does _not_ need to be installed on the distro, but can be linked into an ISV's installer. In the case of RPM, this could be done with librpm. (Probably the pre-4.6 "legacy" RPMv4 API, as that should be what all RPM-based LSB distros support.) For other package managers like dpkg, which don't have a public library, packages would have to be created on-the-fly and installed, much like some installers currently do as well (the ATI binary driver installer comes to mind). - 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.) There are probably a lot of issues with this path, but it might be a good start to experiment with. What do you think? Regards, Denis Washington __ RPM Package Managerhttp://rpm5.org LSB Communication Listrpm-lsb@rpm5.org
Re: The state of LSB Packaging?
On May 18, 2010, at 12:27 PM, Denid Washington wrote: > Hi, > > You might remember me - I'm the one who wrote a sketchy implementation of the > then-discussed "Berlin Packaging API" about two years ago [1]. I have shifted > my focus to other things since then, but since recently have more time again > and my interest on the topic has been sparked again. > Certainly I remember you. > Now I am trying to gather what has happened since then. If I haven't missed > anything, there was not that much to be missed. The packaging list archives > seem to be effectively dead. The only thing I found was thoughts about > uplifting to RPMv4 sprinkled around some LSB Wiki pages, for instance the LSB > 4.1 Project Plan [2]. > Yep. Nothing whatsoever to be missed. The last dialogue I was involved in was (~12/2008): Q: What is the _ONE_ most important item for the LSB 4+ packaging standard? A: Establishing a "standard" version comparison so that "newer" and "upgrade" are well defined. Nothing heard (by me) since. > Now, because I remembered you, Jeff Johnson, to be very constructive, honest > and generally helpful in criticizing my proposal (and always entertaining) > and were very much involved in the whole discussion, I would like to ask you: > what is the state of discussion regarding LSB packaging? Do you know about > any progress on this front since, say, the end of 2008? Any hints would be > very valuable for me, as I am seriously thinking about a second (maybe more > coordinated, complete and consensus-reaching) attempt at working on a new LSB > packaging proposal.. > LSB packaging is as extinct as the Dodo AFAIK. (aside) You might want to look at http://mancoosi.org which is closest (but "research" not "standard", standards are much harder) to evolving something better for software packaging. E.g. the Mancoosi WP5 is sponsoring a SAT depsolver competition this summer that should lead to interesting implementations. There's also http://nixos.org which is attempting "functional" packaging that avoids many of the snarly issues presented by "standard" packaging. I'm still willing to help however I can with LSB+RPM. Its _INSANE_ to continue futile "Packaging War" battles and and no users benefit (but certainly distros/vendors benefit from de facto monopolies through customer lock-in using software packaging). 73 de Jeff __ RPM Package Managerhttp://rpm5.org LSB Communication Listrpm-lsb@rpm5.org
