10:13 p.m.
Is there a FC4 planned? If so, when will the schedule be posted?
http://fedora.redhat.com/participate/schedule/
4 p.m.
On Sun, 2005-01-09 at 23:13 -0500, Robert La Ferla wrote:
Is there a FC4 planned? If so, when will the schedule be posted?
http://fedora.redhat.com/participate/schedule/
I don't have an answer, but it would be *really* nice if that page was
updated. A "PRELIMINARY" schedule for a released product looks shabby.
They could at least mention the FC4 schedule is not finalised.
You could Bugzilla it, and then they might post some information..
4:12 p.m.
On Mon, 2005-01-10 at 23:00 +0100, nodata wrote:
On Sun, 2005-01-09 at 23:13 -0500, Robert La Ferla wrote:
> Is there a FC4 planned? If so, when will the schedule be posted?
>
> http://fedora.redhat.com/participate/schedule/
>
I don't have an answer, but it would be *really* nice if that page was
updated. A "PRELIMINARY" schedule for a released product looks shabby.
They could at least mention the FC4 schedule is not finalised.
You could Bugzilla it, and then they might post some information..
Here is what I know from various things overheard:
1. april or may-ish is the rough final date for fc4
2. work backwards 3ish-months to figure out what fc4test1 will be :)
3. the commitments that are being pushed for fc4 are (I think)
- more selinux!
- gcc4? maybe?
- graphical yum stuff
- extras available in sync with the release.
This is only what I've heard. Nothing definitive. I think mid-may-ish is
most likely so figure sometime around mid-late feb for test1.
I'm not speaking authoritatively - other people can do that - I'm just
relaying reasonably good rumors :)
-sv
6:21 a.m.
On 01/11/2005 02:12:52 PM, Kyrre Ness Sjobak wrote:
> - graphical yum stuff
> - extras available in sync with the release.
:P :-) :-D
If that is true - I would like to something like what smart does, where
you can give a repository priority (or individual packages) and it
won't replace them with same name packages from lesser priority
repositories even if the version number is newer - unless you
specifically up the priority of the package.
7:21 a.m.
On Fri, 2005-01-14 at 12:21 +0000, Michael A. Peters wrote:
On 01/11/2005 02:12:52 PM, Kyrre Ness Sjobak wrote:
>
> > - graphical yum stuff
> > - extras available in sync with the release.
>
> :P :-) :-D
If that is true - I would like to something like what smart does, where
you can give a repository priority (or individual packages) and it
won't replace them with same name packages from lesser priority
repositories even if the version number is newer - unless you
specifically up the priority of the package.
pkgpolicy does some of this
8:03 a.m.
On Fri, 2005-01-14 at 08:21 -0500, Kevin H. Hobbs wrote:
On Fri, 2005-01-14 at 12:21 +0000, Michael A. Peters wrote:
> On 01/11/2005 02:12:52 PM, Kyrre Ness Sjobak wrote:
> >
> > > - graphical yum stuff
> > > - extras available in sync with the release.
> >
> > :P :-) :-D
>
> If that is true - I would like to something like what smart does, where
> you can give a repository priority (or individual packages) and it
> won't replace them with same name packages from lesser priority
> repositories even if the version number is newer - unless you
> specifically up the priority of the package.
>
>
pkgpolicy does some of this
Not in 2.1 and the problem I have with the repo prioritization in smart
is the same problem I have with doing it in yum:
It's terribly confusing, as a setting, for a new user. It is also a good
mechanism to hose up a dependency or other setting for a user who thinks
s/he is experienced.
Essentially repo priority is a super-epoch. It lets the user control how
the version comparison process occurs and put in their own 'override'.
I'm having a hard time thinking of a situation where this situation is
useful to anyone beyond the person who really just needs to learn how to
use --exclude or the 'exclude' and 'includepkgs' repo settings.
Can you explain to me a situation where you see the repository priority
mechanism as a better mechanism for solving a dependency problem? The
only justification I've ever heard for it is to overcome broken
repositories and well, that's fixing the problem in the wrong place. Not
only should you fix the repository you should also consider disabling
that repository in your configuration BECAUSE it is broken.
Seriously, what's the justification for a feature which adds a fair bit
of complexity to any of the dependency resolution code?
-sv
9:29 a.m.
On Fri, 2005-01-14 at 09:03 -0500, seth vidal wrote:
On Fri, 2005-01-14 at 08:21 -0500, Kevin H. Hobbs wrote:
> On Fri, 2005-01-14 at 12:21 +0000, Michael A. Peters wrote:
> > On 01/11/2005 02:12:52 PM, Kyrre Ness Sjobak wrote:
> > >
> > > > - graphical yum stuff
> > > > - extras available in sync with the release.
> > >
> > > :P :-) :-D
> >
> > If that is true - I would like to something like what smart does, where
> > you can give a repository priority (or individual packages) and it
> > won't replace them with same name packages from lesser priority
> > repositories even if the version number is newer - unless you
> > specifically up the priority of the package.
> >
> >
>
> pkgpolicy does some of this
Not in 2.1 and the problem I have with the repo prioritization in smart
is the same problem I have with doing it in yum:
That would be why I couldn't find more about it in the manual. I
suppose I could delete that line from the config.
7064
days inactive
7068
days old
7 comments
6 participants
participants (6)
-
Kevin H. Hobbs -
Kyrre Ness Sjobak -
Michael A. Peters -
nodata -
Robert La Ferla -
seth vidal