Re: Re[2]: project vision

On Thu, 2005-04-14 at 08:44 +0300, Nikita wrote:

> PN> Sounds like you're looking at a depsolver rather than an rpm impl.  Cf
> PN> yum vs rpm and apt vs dpkg.  I'd recommend getting the core jrpm library
> PN> be only dealing with packages and rpmdb, then letting other apps deal
> PN> with repos, etc.
> I have no objection. But if you are writing a library you should take
> into consideration how it will be used.

Sure I'm perfectly aware of that - I'm familiar with rpm as a developer
and liase a lot with those who use rpmlib, rpm-python for installers,
depsolvers and gui.

> PN> I'd say waht you're looking for should be written on top of jrpm not
> PN> core to it.

> As every linux distribution based on rpm has its' own depsolver, 

Partially correct:

Multiple distros use yum
Multiple distros use smart
SuSE uses yast, RHEL uses up2date

That's not necessarily a bad thing

> I
> think original rpm doesn't provide all required features. 

What features do you think rpmlib lacks?  https://bugzilla.redhat.com or
rpm-devel

> So, whynot implement it in jRPM? 

Possibly, although it's not really a proving ground for rpm development
as there is no real take up from the rpm community.  I don't think of
jRPM to be the testing ground for rpm.

I'm here because I'm interested in following development and to provide
rpm side advice if needed.

Eg the current eclipse rpm plugin calls rpm, rather than uses jRPM.  If
you want serious attention driving rpm builds in pure java is probably
going to be a big one:

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%
7E/org.eclipse.cdt-contrib/org.eclipse.cdt.rpm-home/index.html?cvsroot=Tools_Project

Also ensuring building with gcj, etc works.

> Of course, the core should be written first,
> but it is better to aim something greater :)

Sure, but then why not think about the problem you're trying to solve.
If you want to deal with limitations of rpm you may find yourself having
to implement something that isn't compatible.

> What is your vision of jrpm, what are the features it should provide,
> how it will be used?

I see jrpm as a java library that enables processing and generation of
rpm packages and the rpmdb. To provide functionality to other programs
to develop solutions - eg a pure java ant->package or maven->package
without invoking rpm build.  Getting something to make sane packages and
convert a maven setup into a jpackage style repo would be nice (keeping
the pristine sources, etc) - mapping dependencies, etc.

I'm not saying you can't do what you want with the library but for me
writing yet another depsolver isn't what I'd want from jRPM - sure you
can do it with jRPM but it's building the stack.  

Paul



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click