fedora-release-rawhide, et. al.

[Rudolf Kastl]

2010/2/25 James Antill <james at fedoraproject.org>:
> On Thu, 2010-02-25 at 16:29 -0500, Bill Nottingham wrote:
>
>> Going over the various usage cases:
>>
>> 1) Release has not yet branched, want to switch, or use rawhide packges
>>
>>  Currently:
>>   yum install fedora-release-rawhide
>>   yum --enablerepo=rawhide ...
>>
>>  New:
>>   yum --releasever=<next> ...
>>
>> 2) Release has branched; want to pull from never-frozen rawhide devel
>>    stream.
>>
>>  Currently:
>>   yum install fedora-release-rawhide
>>   yum --enablerepo=rawhide ...
>>
>>  New:
>>   yum --releasever=<next> ...
>
>  $releasever just changes the variable, so the URLs are all the same ...
> just with different variables. Specifically:
>
> mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
>
> ...is never going to ==
>
> https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=$basearch
>
> ...I guess if we make sure MM understands what the new numbers mean
> pretty quickly (ie. before branching) this is fine.
>  I'm also not sure what apt/smart are going to do.
>
>> Am I missing something? Do people think this would be better, or worse?
>
>  It removes the ability to have a machine be on rawhide forever, without
> user intervention, but I'm not sure that's a bad thing (but then I don't
> do that).

thats exactly what i personally use since years... but then i just
would drop another repo.conf on top... it would add the inconvenience
of writing/changing the repo file myself and i guess i am not the only
one. on the other hand... what would you really win?

kind regards,
Rudolf Kastl

>
> --
> James Antill - james at fedoraproject.org
> http://yum.baseurl.org/wiki/releases
> http://yum.baseurl.org/wiki/whatsnew/3.2.27
> http://yum.baseurl.org/wiki/YumMultipleMachineCaching
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>