Ok. I'm trying to get the ETSU folks to take on schema duties for 4.2. Perhaps we could also make some mods to it. Hopefully, I'll know if they are going to take this on in a week or so. The project includes the new parser for 4.3, so we'll see.
-- John
On Wed, 16 Feb 2005, Thomas Naughton wrote:
Dave / John,
I agree with Dave's comment and actually hit one myself today when putting the APItest package together. :(
We will need to extend the XML to support dependent RPMS that don't have explicit "Requires" entries in their rpm spec file.
I also agree that we've bastardized the XML elements and a revisit would be worth the time. I would also say that our <rpmlist> and <rpm> tags are also specific to RPM and the new Debian stuff might benefit from a more agnostic naming scheme (I don't have any good suggestions off the top of my head since we already use <package>.)
I say we draft a DTD or Schema for the existing config.xml, and then see what/how we can extend/enhance it to make it "More Better" (TM).
--tjn
_________________________________________________________________________ Thomas Naughton [EMAIL PROTECTED] Research Associate (865) 576-4184
On Wed, 16 Feb 2005, John Mugler wrote:
To restate this in my own simple language, bottom line is Dave's tools work, but the rpm's in the packages do not necessarily list all their
dependancies.
Would a better fix in the long term be to get the rpm's right, i.e. list all the dependancies? Or will we always see corner cases where we'll need a
tag like Dave suggested at the package level, '<requires>', to get things to resolve?
-- John
On Wed, 16 Feb 2005, Lombard, David N wrote:
Thomas,
Dependency resolution can only be performed at the rpm level if the rpms enumerate their dependencies. As I explained, pfilter is an example (oda with its need for mysql, perl-DBD-MySql and perl-DBI is another) of an rpm that doesn't make explicit rpm dependencies. We could argue if the particular packages should, e.g., an OSCARized package should, while perhaps a generic package need not, etc), but the reality is that some don't. Given that reality, update-rpms has no basis to ensure dependencies that are not enumerated.
In the case of pfilter, it just so happens that the distros that I'm aware of all include iptables in their base; as long as that, ipchains, or even ipfwadm are included, pfilter will work. So, there's a circumstantial reason why pfilter doesn't actually need to <rpmlist> iptables.
oda, on the other hand, does need to somehow indicate a requirement for mysql, as there are no explicit rpm dependencies for it (or the other two I listed above).
The current state of the config.xml files is, well, sloppy. In some cases, the only <rpmlist> items are those that must be explicitly listed to satisfy dependencies that are otherwise not enumerated. In other cases, though, many dependencies were listed, needed or not.
At the end of the day, we have overloaded <rpmlist>; to address this we either need to remove the need for the overload, or remove the overload with another mechanism.
The latter may be easier, and I would suggest a
<rpmlist> ... <rpm>fred</rpm> <requires>barney</requires> ... </rpmlist>
where the new <requires> rpms are listed as to-be-installed, but never listed as to-be-deleted.
------------------------------------------------------- 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 _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
