Michael Mansour wrote:
> 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.

To Hardcode or Not To Hardcode

Well, to be honest, we've been hardcoding Dag's repository into the 
yum-conf file for all of S.L. 3.0.x, and so far, all of S.L. 4.x.  There 
is no need to change the hard coded release number just because you move 
from S.L. 3.0.1 or S.L. 3.0.4, because Dag's recompiles work for all 
S.L. 3.0.x.

I really believe that with Axel's, it can be the same way.  Just point 
yum to the el3 or el4, whichever is correct, and away you go.  No need 
to change between releases.

With S.L. 4.x, since we are using yum 2.2, it should be easy to actually 
have an rpm, something like yum-conf-axel, that will put his repo into 
your yum.repos area.

Troy

-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/CSS  CSI Group
__________________________________________________