This was not the purpose of my post, and you have misunderstood what I was
getting at in attempt to post your works.
I don't have the budget to pay $350-$700 to redhat each year for RHEL
(although the educational institution pack is tempting), nor will I run a
server on fedora (too much change), nor do I have time to build all the
security updates for redhat9 myself once april rolls around and the errata
goes away. I already have a debian server with loads of storage space. So
virtual hosting a yum repository is not a far cry from reality. I have no
intention of mixing yum and apt on a debian box for installs, as this is an
instant recipe for disaster. I simply need to be able to generate the
headers for the fedora core rpms so that others can use yum to pull from a
local mirror for better bandwidth conservation.
To that end, the debian stable packages are seemingly too old for yum at
present, and some tweaking of code is going to be necessary on my part to
make this function. Debian stable rpm packages are for rpm 4.0.3, so I
thought I would give yum 1.0.3 a shot. It builds and installs successfully,
however the pullheaders.py attempts to load rpm404 which seems non-existent
as the traceback below states.
testing:/var/www/pub/pub/redhat/linux/updates/9/en# yum-arch .
Traceback (most recent call last):
File "/usr/bin/yum-arch", line 22, in ?
import pullheaders
File "pullheaders.py", line 24, in ?
ImportError: No module named rpm
I've never had to do much digging in yum because on redhat and fedora it's
always Just Worked (thanks seth et al.!)
Now this is finals week for us, so I have even less free time, but it would
seem that I need to either install or build a version of RPM from this
decade, and possibly look into rebuilding python to make this function
within my effective budget of 0 dollars.
I hate to re-invent the wheel, so I thought I'd ask if someone already had
it running on a debian box, and just plagiarize what they had done. Since
this does not seem to be the case, I'll do what I can to get it functional,
document it, and post it for others to use if they think I'm sane enough to
trust.
</rant>
Somewhere in the above article is a traceback, and if anyone wants to point
me in the proper direction or offer up ideas, I'm all ears.
--On Thursday, November 20, 2003 10:06:14 -0500 "Robert G. Brown"
<rgb@xxxxxxxxxxxx> wrote:
> On Thu, 20 Nov 2003, Jim Perrin wrote:
>
>> Actually, what I've run into seems to be a python module problem, in
>> when it trys to pull the headers. I'm not sure if the proper module
>> exists for debian, or if it's simply due to the ancient version of
>> python included in debian/stable. I'll keep digging, and post what I
>> find.
>
> Somebody posted earlier today asking what yum's advantages were relative
> to apt and friends. I didn't respond but this indicates one of them in
> a nutshell: "ancient version of python included in debian/stable".
>
> Yum gives you a broader range of choice at the stable end, or has up to
> now. Because of the layers of control (and control over layers) it
> provides with respect to repository lists, and because it appears that a
> lot of primary development teams are "yummifying" their primary package
> distribution sites, it seems likely that in the near future yum will
> provide one with a great deal of control indeed and provide relatively
> easy and low risk pathways to remain current on whole branches of
> distribution trees without destabilizing your enterprise. I was very
> intrigued to observe the Mozilla response earlier today -- upgrade
> mozilla to current by the simple expedient of slapping a mozilla
> repository entry in your /etc/yum.conf, and (we hope) thereafter
> automagically install updates as they appear in the mozilla tree.
>
> I'd also have to say that in some ways "we ain't seen nothin' yet". Yum
> is being very aggressively and intelligently developed. APT is a
> relatively mature tool, but maturity also creates a degree of
> inflexibility as more and more add-ons rely on a high-end API that was
> developed long ago. Yum so far has been developed as an intermediate
> layer on top of a very low level tool (rpm), and still has relatively
> little add-on-ware that rely on its API. In fact, its API in some sense
> isn't even fully defined except by its man pages, and is utterly open to
> change as discussions on this list indicate. Consequently it can evolve
> far faster with minimal impact.
>
> Yum 2 is already well advanced over yum 1, but yum 3 is where things
> will get very interesting indeed. Complete changes in the way header
> information is managed and a whole lot more. Should be exciting.
>
> Yum by its mere existence is also stimulating the APT team, Red Hat,
> maybe Mandrake (all of whom have high end tools in the same space) into
> rethinking lots of things, which is likely a very good thing. Is yum
> "better" than up2date, apt, urpmi? Hard to say, and possibly even a
> matter of taste, as all of these likely CAN be used to accomplish the
> basic tasks of managing an installation in a more or less automated way.
> However, most of the sysadmins of large scale networks and compute
> clusters on this list seem pretty happy with yum.
>
> As the yum article I posted yesterday makes clear, it is VERY EASY to
> set up a yum repository yourself, install the yum client on your LAN,
> and "instantly" have complete revision/update control of your entire
> network. Even a relative newbie to systems administration can likely
> manage it. To a pro, it is a piece of cake and chock full of the very
> features they'd ask for, added by a professional systems administrator
> (Seth) at the request of or with patches provided by professional
> systems administrators who use yum themselves (maybe 80% of the list).
>
> This is arguably the final difference. Yum is a professional toolset
> from the outset. It can be used by a systems administrative novice --
> indeed it is designed so that it will automatically maintain systems
> owned by people who are utterly clueless about the command line if
> installed from an RPM built by somebody who does (with the appropriate
> yum.conf and chkconfig %post). However, it was designed top to bottom
> to facilitate the administration of large-scale networks of linux
> systems, INCLUDING those belonging to clueless users on which the
> toplevel admin has no root control, by systems administrators.
>
> I don't know all the details of the other tools, but I don't think any
> of them were developed in quite this way. up2date is clearly a
> corporate tool designed to tie Red Hat users to a specific Red Hat
> supported revisioning process. urmpi seems to do a similar sort of
> thing for Mandrake. APT appears to come from the other end, to permit
> users to completely install and update their systems from a single
> monolithic repository tree. In this yum has transcended it yup roots
> and is pretty much completely divorced from distribution and designed as
> much to support the real needs of real sysadmins as anything else.
>
> r-is-for-feeling-religious-today-gb
>
> --
> Robert G. Brown http://www.phy.duke.edu/~rgb/
> Duke University Dept. of Physics, Box 90305
> Durham, N.C. 27708-0305
> Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
>
>
>
> _______________________________________________
> Yum mailing list
> Yum@xxxxxxxxxxxxxxxxxxxx
> https://lists.dulug.duke.edu/mailman/listinfo/yum
