search

dnbert / prm

PRM Allows you to quickly build package repositories, inspired by Jordan Sissels' FPM
MIT License
250 stars 33 forks source link

rpm primary.xml <package> missing <rpm:requires> and <rpm:provides> #42

Open pusateri opened 9 years ago

pusateri commented 9 years ago

These are not included in the primary.xml file and there are no errors. I installed the rpm gem ('gem install rpm') but that didn't help. It seems as though in create_primary_xml(), rpm.requires and rpm.provides are empty but they shouldn't be. If I use the shell command 'createrepo .', the primary.xml file correctly includes the requires and provides tags.

dnbert commented 9 years ago

Thanks for letting me know! Can you show me what command you ran and what package you were trying to apply to your repository? I'd like to replicate this, to see why it didn't apply.

pusateri commented 9 years ago

The command I ran was "prm -t rpm -a x86_64 -r fc20 -p hypd" on Fedora 20. I installed prm with 'gem install prm'. You can find the repo with an RPM to test at http://cj.bangj.com/~pusateri/prm.tar.gz. I also tried this on a FreeBSD 9.1 machine with the same result.

trel commented 8 years ago

I am seeing the same thing.

Every RPM I add via prm, generated by me or not, has no entries for either <rpm:requires> or <rpm:provides>. This makes the packages listed in the repository available for direct installation by reference, but not if they are declared as dependencies by another package - they're not advertised, so they're not found when yum searches the repolist.

trel commented 8 years ago

It appears https://github.com/dnbert/prm/blob/master/lib/prm/rpm.rb#L232 and https://github.com/dnbert/prm/blob/master/lib/prm/rpm.rb#L247 and https://github.com/dnbert/prm/blob/master/lib/prm/rpm.rb#L263 are always evaluating to false.

I don't see where rpm.provides et al are being populated?

I confirm seeing no <rpm:conflicts> entries in the primary.xml either for my packages where conflicts are declared.

sigil66 commented 7 years ago

Actually the problem is in the string addition, after generating the relevant lines. Even after correcting these, the resulting xml creates yum explosions.