FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 02-25-2010, 09:03 PM
Matthew Miller
 
Default fedora-release-rawhide, et. al.

On Thu, Feb 25, 2010 at 04:32:38PM -0500, Seth Vidal wrote:
> > streams, run "yum --releasever <whatever> install/upgrade fedora-release"
> > yum --releasever=<next> upgrade
> > Am I missing something? Do people think this would be better, or worse?
> gpg signatures.
> changing the releasever points to a different set of repos and,
> potentially, different (or no) sigs.
> how will that work?

Have a small repository which just holds fedora-release packages for all
the different releases, and that repo can have its own key.



--
Matthew Miller <mattdm@mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Computing & Information Technology
Harvard School of Engineering & Applied Sciences
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-25-2010, 09:05 PM
James Antill
 
Default fedora-release-rawhide, et. al.

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).

--
James Antill - james@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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-25-2010, 10:14 PM
Jesse Keating
 
Default fedora-release-rawhide, et. al.

On Thu, 2010-02-25 at 16:29 -0500, Bill Nottingham wrote:
> Am I missing something? Do people think this would be better, or
> worse?

I muffed up fedora-release on rawhide, but here was my plan.

rawhide:
fedora-release requires fedora-release-rawhide
All repos except for rawhide disabled. Rawhide enabled.
This state never changes, the only thing that changes is package
version goes up each time we branch. 13, 14, 15, etc...

branched:
fedora-release does not require fedora-release-rawhide
fedora and updates-testing repos enabled, all others disabled

release:
fedora-release does not require fedora-release-rawhide
fedora and updates repos enabled, all others disabled.


With this scenario, I do believe we'll have the functionality we want.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-26-2010, 04:25 AM
Matt Domsch
 
Default fedora-release-rawhide, et. al.

On Thu, Feb 25, 2010 at 05:05:38PM -0500, James Antill wrote:
> $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.

MM now has redirects for fedora-14 to rawhide.

Unfortunately, that's a manual step that has to be done at the
branchpoint - I haven't taught the MM directory traversal script how
to automatically detect the branch and move the redirects. But one
script every 6 months, I can live with.

--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-26-2010, 07:53 AM
Till Maas
 
Default fedora-release-rawhide, et. al.

On Thu, Feb 25, 2010 at 05:05:38PM -0500, James Antill wrote:

> $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

It seems that it would be enough to rename the repo from rawhide to
fedora-rawhide in MirrorManager, so that one can use
--releasever=rawhide

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-26-2010, 07:55 AM
Till Maas
 
Default fedora-release-rawhide, et. al.

On Thu, Feb 25, 2010 at 04:29:31PM -0500, Bill Nottingham wrote:

> Am I missing something? Do people think this would be better, or worse?

It makes it harder to run repoquery against rawhide, because one would
need to adjust the releasever value everytime rawhide is branched. But
if --releasever=rawhide worked, then this would be better than having to
install the rawhide-release package.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-26-2010, 09:04 AM
Rudolf Kastl
 
Default fedora-release-rawhide, et. al.

2010/2/25 James Antill <james@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@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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-26-2010, 02:33 PM
Matt Domsch
 
Default fedora-release-rawhide, et. al.

On Fri, Feb 26, 2010 at 09:53:16AM +0100, Till Maas wrote:
> On Thu, Feb 25, 2010 at 05:05:38PM -0500, James Antill wrote:
>
> > $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
>
> It seems that it would be enough to rename the repo from rawhide to
> fedora-rawhide in MirrorManager, so that one can use
> --releasever=rawhide

I've added these redirects now, so in an hour or so you can use
--releasever=rawhide.

--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-26-2010, 03:14 PM
Till Maas
 
Default fedora-release-rawhide, et. al.

On Thu, Feb 25, 2010 at 04:29:31PM -0500, Bill Nottingham wrote:

> New:
> yum --releasever=<next> upgrade
>
> Am I missing something? Do people think this would be better, or worse?

Is the releasever option a yum F13 feature? On F12 it complains that
it is not a valid option.

Also repoquery returns F12 results but accepts --releasever:
$ repoquery --releasever=rawhide --repoid=fedora kernel
kernel-0:2.6.31.5-127.fc12.x86_64

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 02-26-2010, 03:42 PM
Bill Nottingham
 
Default fedora-release-rawhide, et. al.

Jesse Keating (jkeating@redhat.com) said:
> On Thu, 2010-02-25 at 16:29 -0500, Bill Nottingham wrote:
> > Am I missing something? Do people think this would be better, or
> > worse?
>
> I muffed up fedora-release on rawhide, but here was my plan.
>
> rawhide:
> fedora-release requires fedora-release-rawhide
> All repos except for rawhide disabled. Rawhide enabled.
> This state never changes, the only thing that changes is package
> version goes up each time we branch. 13, 14, 15, etc...

How about just have fedora-release contain only the rawhide
repo, and have 'Obsoletes: fedora-release-rawhide < %{version}'?

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 09:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org