old_testing_critpath notifications

François Cami fdc-lists at fcami.net
Thu Dec 2 17:20:25 UTC 2010


On Thu, Dec 2, 2010 at 6:03 PM, Adam Williamson <awilliam at 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:
http://kojipkgs.fedoraproject.org/mash/rawhide-20101202/logs/critpath.txt
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
users.

>> And packages with enough known users should always land in critpath,
>> 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.

>> At this point, non-critpath packages may be left to their maintainers' wishes.
>
> maybe we could have a three-tier system - critpath, commonly used,
> other.

Works for me, as long as "commonly" used is at the very least
smoke-tested, but I guess that was your intention since there is an
"other" set :)

> but we don't really have any very reliable methods for
> determining use of packages yet.

We could extend smolt to do so.

François


More information about the devel mailing list