On Sat, 9 Aug 2003, Joe Cooper wrote:
> Perhaps your user data is different than the data I need to distribute,
> but mine stays mostly the same between revisions--in a 10MB file, maybe
> 250KB changes. I've been trying to figure out how to do a clean
> versioned rsync-based packaging scheme, maybe even one that can update
> the RPM DB with its version info, but it hasn't come to me in a vision
> yet, nor has my spirit guide shown me the way. I may have to resort to
> formal design process and other such voodoo.
Of course there are lots of ways to do it -- hacks and script-foo and
made-up schema galore. The shame of it is that most of what one does
with it all is reinvent wheels, probably not as well as existing
packaging schemes already do the basic packaging itself. Well, its also
a shame that data (only) distribution is in some ways fundamentally
simpler than binary/library distributions, but the rpm suite, at least,
appears to have been customized so much in direct support of the latter
that the former is difficult to broken within the toolset itself, AFAIK
(which may not be far enough, as I'm far from being a true expert with
rpm's in spite of the fact that I build them from scratch often enough).
And without a working rpm-based schema, yum becomes irrelevant.
I also wasn't suggesting that SETH (or any software authors of yum or
anything else) would make money if yum could do this, only that money
could be made, primarily by those folks interested in distributing
valuable and somewhat volatile data in this way for money. The only way
I could see Seth & Michael making money would be for somebody who wants
the feature desperately but isn't able to help develop it themselves to
pay S&M to add it to yum. Alternatively, GPL being what it is, if one
of the many companies messing with drug databases for handhelds or
workstations or any other "valuable data" product needs to hack yum so
they can use it to support an automagic distribution process without
root privileges or rootspace storage being required, they can, and they
can even contribute the resulting hacks back to the project if they end
up with something nice.
I mean, one COULD likely generalize yum so it worked with all packaging
systems (a common interface on top of apt, rpm, even tgz, each
supporting versioning and obsoletes as best it can)(and don't worry I'm
NOT suggesting that this be done, only that it's just a matter of a
certain amount of insane coding away:-). One COULD probably hack yum so
that it doesn't use rpm-linked tools directly anyway but instead has its
own data interface and parses things out completely internally and can
even unpack rpm's and install them all by itself, in which case of
course one could make it do whatever one liked (ditto, only if one were
cracked).
However, I agree (as I said yesterday) that with rpm semi-broken for
achieving this purpose as it stands and little motivation on anybody's
part to hack around this in yum until that is no longer true (or the
hacker themselves has means, motive and opportunity on their own) we
should probably drop this idea or take it offline at least until
somebody can show that rpm's built thus-and-such would do what is
required just perfectly. I think that they can be made to "work" as
they are, but the dependency and database features required to make them
work well (without --nodeps and still using the default database read
only to resolve software dependencies of non-software data packages,
minimally) are either missing or arcane and not obvious from the
admittedly nearly useless man pages. Perhaps my reading the rpm source
(or hacking the source and trying to get the hacks accepted by the
authors) would be a better first step than bugging this list about it in
the meantime...;-)
And just to set the record straight, I don't have any particular
entrepreneurial application of all this in mind or expectations of money
myself as a humble and already too busy physicist. Although I do think
that if this whole idea were perfectly implemented, there would be
plenty of money made from it -- probably by Red Hat and IBM and some of
the other well-funded and committed linux companies and their
consultative clients.
rgb
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
