take a look at this little script
rpm=$1
arch=$2
rpm -qa \
| grep $rpm \
| while read rpm
do
found=`rpm -qi $rpm | grep $arch`
[ "$found" ] && echo $rpm
done
arch=$2
rpm -qa \
| grep $rpm \
| while read rpm
do
found=`rpm -qi $rpm | grep $arch`
[ "$found" ] && echo $rpm
done
a colleage (however it`s spelled) of my made that and it can find the architectures :D
usage (when put in a file called rpmscript):
rpmscript hal i386
hope this helps.
good luck,
Mark.
2007/4/6, seth vidal <skvidal@xxxxxxxxxxxxxx>:
On Thu, 2007-04-05 at 23:05 +0200, Mark wrote:
> it sounds good.
>
> but how is this flat file gonna be managed?
cvs, I'd suspect.
> will there be a rpm that`s updating the flatfile with other rpm names
> incase they need to be added? or will it be a solid flat file that is
> gonna be delivered with fedora core 7 and won`t be updated?
I'd say it's a file that can be downloaded from any repo. The pkgs in
the combined set of these files from all repos would be removed, if
present. Then we could just have the file be present in updates-released
and be done with it.
> whatever one it is.. i wouldn`t go for a flatfile.. i think it`s
> better to make use of sqlite (yea yea.. that`s flatfile based).
> sqlite is needed for yum anyway so why not just use it for this
> aswell.
yes, but sqlite files are no fun to put into cvs or $SCM
> but something different.. isn`t the basic problem of this all in yum
> or rpm? (i think yum) and wouldn`t it be better to just fix that.
yes, but as I said earlier, it is way simpler to fix the issue at the
yum level than at the rpm level.
-sv
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
