On Thu, Dec 2, 2010 at 6:31 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Thu, 2010-12-02 at 18:20 +0100, François Cami wrote:
> On Thu, Dec 2, 2010 at 6:03 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
> > On Thu, 2010-12-02 at 13:20 +0100, François Cami wrote:
> >> Of course, we could look at things differently: for a package to be
> >> marked critpath, it should have users or be a dependency of some other
> >> package with users.
> > This is pretty inevitably implicit in the current definition of critpath
> > - packages that are necessary to boot the system and use it. :) Okay,
> > there's slightly unexpected cases like openldap, which isn't necessary
> > for most people to login and use their systems but gets brought in
> > because it's a dependency of various auth mechanisms which *optionally
> > support* LDAP, but even that is obviously used by >0 people.
> jlaska just gave me the list of packages marked critpath in rawhide:
> 389-ds, cobbler, httpd, libvirt, mysql, postgresql, puppet, vsftpd are
> not in the list. My guess is therefore that most server packages are
> completely ignored by the critpath definition. And we have server
Ah. I misread you: I thought you meant to add that to the current
definition of critpath packages, not to replace the current critpath
definition with simply "anything with users".
Make that "anything with enough users for us to care", especially if
said users participate in the process, and that's about it.
> >> And packages with enough known users should always land
> >> otherwise we might break systems users depend on.
> > That doesn't fit in with the current function-based definition, so your
> > proposal is to change that?
> Yes. Note that the current function-based definition is contained in
> the "have users"-based one, as long as Fedora is used on the desktop,
> that is.
Right, but it massively increases the range of critpath packages (which
would only exacerbate the problem under discussion unless we made
critpath testing less rigorous), and loses the initial purpose of the
critpath policy. I think really what you want is the three-tier system
so that 'not important' packages can be allowed to go through without
That, and catch regressions in updates to well-used packages before
they're pushed. And that includes server packages.
> > but we don't really have any very reliable methods for
> > determining use of packages yet.
> We could extend smolt to do so.
smolt's still opt-in and always will be, AFAIK, because there'd be way
too much of a Slashdot drama if it weren't.
Yes it is and rightly so. However, it contains data about 200K active
systems at the moment:
Data about CPU, RAM, Language, etc... But no data about packages yet.