Re: Problem with some RPM's

On Mon, 2002-11-11 at 09:07, John Berninger wrote:
> I know the response should be inlined, but I'm feeling a bit lazy this
> morning, so forgive me.
> 
>         Technically, it would be trivial to use the filename to create
> the RPM header, but that would simply push the problem back to the
> package retrieval stage.  The client gets from the server a list of
> package names, version, and releases, and then attempts to download that
> package by building the filename itself.

Fraught with danger. We'll never do this. 

> 
>         (Hunter will correct me if I'm wrong.)
> 
>         The best interim solution is to simply rename the files that IBM
> distributes to conform to what Current / RHN expects.  I'll work with
> Hunter on a better (i.e. more permanent) solution once he's out from
> under the horde of lemmings that have attacked him this week.

Won't do a damn bit of good.

Current has never, will never, and probably CAN'T parse the filename of
the rpm to determine the version or release.

We query the rpm directly - the filename is only used as a name of a
file. 

If I had to guess, I'd say those rpm's are hosed in some IBM way.

> 
> On Mon, 11 Nov 2002, Klaus Steinberger wrote:
> 
> > Hello,
> > 
> > I've got the following problem with some RPM's from IBM for the Tivoli 
> > Storage Manager Software:
> > 
> > When I add them to a channel on my current server, anything run's well 
> > until a machine want's to fetch the header for one of those packages. I 
> > get then the following error Message:
> > 
> > Fetching rpm headers...
> > There was a fatal error communicating with the server.  The message was:
> > 404: "Not Found" while attempting to get
> > $RHN/lmugar-i386-7.3/getPackageHeader/TIVsm-BA-5.1.5-0.i386.hdr
> > 
> > After some investigation I found out, that getPackageHeader directory 
> > contain's indeed the files, but without the version number:
> > 
> > [root@etprd02 getPackageHeader]# ls TIV*
> > TIVguid.i386.hdr              TIVsm-BA.GPFS.i386.hdr
> > TIVsm-API.i386.hdr            TIVsm-BA.i386.hdr
> > TIVsm-API.msg.de_DE.i386.hdr  TIVsm-BA.msg.de_DE.i386.hdr
> > TIVsm-API.msg.es_ES.i386.hdr  TIVsm-BA.msg.es_ES.i386.hdr
> > TIVsm-API.msg.fr_FR.i386.hdr  TIVsm-BA.msg.fr_FR.i386.hdr
> > TIVsm-API.msg.it_IT.i386.hdr  TIVsm-BA.msg.it_IT.i386.hdr
> > TIVsm-API.msg.ja_JP.i386.hdr  TIVsm-BA.msg.ja_JP.i386.hdr
> > TIVsm-API.msg.ko_KR.i386.hdr  TIVsm-BA.msg.ko_KR.i386.hdr
> > TIVsm-API.msg.pt_BR.i386.hdr  TIVsm-BA.msg.pt_BR.i386.hdr
> > TIVsm-API.msg.zh_CN.i386.hdr  TIVsm-BA.msg.zh_CN.i386.hdr
> > TIVsm-API.msg.zh_TW.i386.hdr  TIVsm-BA.msg.zh_TW.i386.hdr
> > 
> > Also the original files do not contain the version number in the name.
> > That are the rpm's:
> > 
> > [cdadmin@bagheera RPMS]$ ls TIV*
> > TIVguid.i386.rpm              TIVsm-API.msg.ko_KR.i386.rpm 
> > TIVsm-BA.msg.fr_FR.i386.rpm
> > TIVsm-API.i386.rpm            TIVsm-API.msg.pt_BR.i386.rpm 
> > TIVsm-BA.msg.it_IT.i386.rpm
> > TIVsm-API.msg.de_DE.i386.rpm  TIVsm-API.msg.zh_CN.i386.rpm 
> > TIVsm-BA.msg.ja_JP.i386.rpm
> > TIVsm-API.msg.es_ES.i386.rpm  TIVsm-API.msg.zh_TW.i386.rpm 
> > TIVsm-BA.msg.ko_KR.i386.rpm
> > TIVsm-API.msg.fr_FR.i386.rpm  TIVsm-BA.i386.rpm 
> > TIVsm-BA.msg.pt_BR.i386.rpm
> > TIVsm-API.msg.it_IT.i386.rpm  TIVsm-BA.msg.de_DE.i386.rpm 
> > TIVsm-BA.msg.zh_CN.i386.rpm
> > TIVsm-API.msg.ja_JP.i386.rpm  TIVsm-BA.msg.es_ES.i386.rpm 
> > TIVsm-BA.msg.zh_TW.i386.rpm
> > 
> > 
> > 
> > So I suspect that IBM built their RPM's with the version number in the 
> > file name, but distributed them differently.
> > 
> > Of course I could change the filename's of the RPM's and then recreate 
> > the channel as a workaround.
> > 
> > But do you think we could do something inside current to get around this 
> > problem, like not creating the .hdr file's from the filename but instead 
> > according to the data inside the RPM?
> > 
> > Sincerely,
> > Klaus Steinberger
> > 
> > -- 
> > Klaus Steinberger         Maier-Leibnitz Labor
> > Phone: (+49 89)289 14287  Am Coulombwall 6, D-85748 Garching, Germany
> > FAX:   (+49 89)289 14280  EMail: [email protected]
> > URL: http://www.physik.uni-muenchen.de/~k2/
> > 
> > In a world without Walls and Fences, who needs Windows and Gates
> > 
> > _______________________________________________
> > Current-server mailing list
> > [email protected]
> > http://lists.dulug.duke.edu/mailman/listinfo/current-server
> 
> -- 
> Thank you,
> John Berninger
> 
> Systems Administrator		[email protected]
> Department of Mathematics	Box 8205, Harrelson Hall
> NC State University		Raleigh, NC 27695
> Phone:  (919)515-6315		Fax:	(919)515-3798
> 
> GPG Key ID: A8C1D45C
>         Fingerprint: B1BB 90CB 5314 3113 CF22  66AE 822D 42A8 A8C1 D45C
> --
> _______________________________________________
> Current-server mailing list
> [email protected]
> http://lists.dulug.duke.edu/mailman/listinfo/current-server
> 
> 
-- 
Hunter Matthews                          Unix / Network Administrator
Office: BioScience 145/244               Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02  9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.