SCIENTIFIC-LINUX-USERS Archives

May 2005

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Michael Mansour <[log in to unmask]>
Reply To:
Michael Mansour <[log in to unmask]>
Date:
Wed, 4 May 2005 12:34:11 +1000
Content-Type:
text/plain
Parts/Attachments:
text/plain (72 lines)
Hi Axel,

> Hi,
> 
> On Tue, May 03, 2005 at 11:36:22PM +1000, Michael Mansour wrote:
> > > Michael Mansour wrote:
> > > > Just as a note. I'm currently testing the ATrpms repository
> > > > together with SL4.  Axel Thimms (the ATrpms owner) is almost
> > > > ready with fully supporting RHEL3/4.
> 
> > > > The "4.0" is the problem. Axel supports what RHEL4 outputs, a
> > > > straight "4":
> > > > 
> > > > http://apt.atrpms.net/rhel/4/en/i386/at-stable
> > > > 
> > > > I realise it's just a matter for replacing "$releasever" with
> > > > "4.0", and also realise why SL 4.0 is there (for 4.0.1 as update
> > > > 1, 4.0.2 as update 2, etc).  But just thought I should mention
> > > > it on the list in case other SL users face the issue when he
> > > > officially announces support for RHEL.
> 
> Perhaps I should setup symlinks 4.0, 4.0.1, etc. pointing to 4? OTOH
> hardwiring the 4 in the config file isn't as bad with an 18 months
> release cycle.

I'd expect when upgrading SL 4.0 to 4.0.1, 4.0.2, etc, that many .rpmsave
files would be created, regardless of whether we had "4" or "$release" in the
/etc/yum.repos.d/atrpms.repo file.

If an admin was to make the changes within the /etc/yum.conf file, then they
should expect to do more work in modifying their yum.conf file. However, if an
admin was using the dropfile directory /etc/yum.repos.d/atrpms.repo, then no
work would actually need to be done if the atrpms.repo file is correctly
setup, since the yum packages supplied with SL4 don't (yet) have a atrpms.repo
file in there, so no .rpmsave would interfere with an admin created
atrpms.repo file.

I'd personally like to use the variable $releasever, but if it poses problems
then it's not such a bad thing to simply just change it to "4", especially
with the long release cycle.

> > > I also didn't know that Axel was going to be doing compiles for
> > > RHEL based releases.  That is good to know as well.
> 
> > Yeah, I normally use alot of his RPMs on my server builds so was happy to 
> > hear a couple of months ago he had intentions to support el3/4.
> > 
> > Although he has them on-line, they have version numbers of el2.9999 and 
> > el3.9999 so hasn't announced it officially yet. He's in the very final 
> > stages now of making the packages el3 and el4, before officially announcing 
> > ATrpms support of the rhel3/4 releases.
> 
> The missing bits are
> 
> o proper (public) mirroring of SL (need to upgrade the server's hard
>   disk capacities, hopefully next week).
> 
> o rebuilding packages against RHEL & updates (e.g. against the latest
>   updated kernels).
> 
> I'd welcome any testing/bug reports etc. I'm already on a couple of 
> SL lists and you can also use bugzilla.atrpms.net for bug reports/package
> requests etc.

I'm currently in the process of building many SL4 production systems, I
haven't yet reached the stage of installing ATrpms packages yet, but when I do
and if there's problems, you'll be the first to know! :)

Your repo is much appreciate, thankyou.

Michael.

ATOM RSS1 RSS2