2:33 p.m.
I did a minimal install yesterday, and was surprised to find that
cairo, and a bunch of X libs were still installed.
The dependancy chain that pulled them in looks like this..
policycoreutils -> dbus-glib -> gobject-introspection -> fontconfig -> cairo
Could any part of that chain have its dependancies relaxed ?
Dave
4:21 p.m.
On Mon, Oct 25, 2010 at 3:33 PM, Dave Jones <davej(a)redhat.com> wrote:
I did a minimal install yesterday, and was surprised to find that
cairo, and a bunch of X libs were still installed.
The dependancy chain that pulled them in looks like this..
policycoreutils -> dbus-glib -> gobject-introspection -> fontconfig -> cairo
This is fixed in F15 in multiple ways (restorecond is split out of
policycoreutils, and dbus-glib no longer deps on
gobject-introspection, and g-i no longer depends on cairo)
Could any part of that chain have its dependancies relaxed ?
Unfortunately we didn't notice this dependency until pretty late in
F14...I'm not sure what can be done reasonably at this point, since
all of these packages are critical path.
4:45 p.m.
On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters <walters(a)verbum.org> wrote:
Unfortunately we didn't notice this dependency until pretty late in
F14...I'm not sure what can be done reasonably at this point, since
all of these packages are critical path.
Though I will say that if this was determined to be a blocker, here's
a really safe minimal fix:
4:55 p.m.
Colin Walters (walters(a)verbum.org) said:
On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters
<walters(a)verbum.org> wrote:
>
> Unfortunately we didn't notice this dependency until pretty late in
> F14...I'm not sure what can be done reasonably at this point, since
> all of these packages are critical path.
Though I will say that if this was determined to be a blocker, here's
a really safe minimal fix:
AFAIK, there's nothing on the release criteria which make this a blocker.
You can submit an update whenever for it, of course.
Bill
5:52 p.m.
On Mon, 2010-10-25 at 17:55 -0400, Bill Nottingham wrote:
Colin Walters (walters(a)verbum.org) said:
> On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters <walters(a)verbum.org> wrote:
> >
> > Unfortunately we didn't notice this dependency until pretty late in
> > F14...I'm not sure what can be done reasonably at this point, since
> > all of these packages are critical path.
>
> Though I will say that if this was determined to be a blocker, here's
> a really safe minimal fix:
AFAIK, there's nothing on the release criteria which make this a blocker.
You can submit an update whenever for it, of course.
It's worth pointing out that we're not religious about the criteria: we
want to have criteria to cover each blocker issue, but that doesn't mean
that no issue can ever be a blocker unless it meets the existing
criteria. When we come across an issue that is widely agreed ought to be
a blocker, but doesn't meet the existing criteria, we write a new
criterion. :)
Having said that, I don't think this seems serious enough to be a
blocker, though obviously we'd like the minimal install to be as minimal
as possible. Does it cause major problems for any spins? I doubt it, I
expect most of them will have cairo for one reason or another anyway.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:56 p.m.
On Mon, Oct 25, 2010 at 11:52 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Mon, 2010-10-25 at 17:55 -0400, Bill Nottingham wrote:
> Colin Walters (walters(a)verbum.org) said:
> > On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters <walters(a)verbum.org>
wrote:
> > >
> > > Unfortunately we didn't notice this dependency until pretty late in
> > > F14...I'm not sure what can be done reasonably at this point, since
> > > all of these packages are critical path.
> >
> > Though I will say that if this was determined to be a blocker, here's
> > a really safe minimal fix:
>
> AFAIK, there's nothing on the release criteria which make this a blocker.
> You can submit an update whenever for it, of course.
It's worth pointing out that we're not religious about the criteria: we
want to have criteria to cover each blocker issue, but that doesn't mean
that no issue can ever be a blocker unless it meets the existing
criteria. When we come across an issue that is widely agreed ought to be
a blocker, but doesn't meet the existing criteria, we write a new
criterion. :)
Having said that, I don't think this seems serious enough to be a
blocker, though obviously we'd like the minimal install to be as minimal
as possible. Does it cause major problems for any spins? I doubt it, I
expect most of them will have cairo for one reason or another anyway.
I wouldn't expect it to affect the usual spins on s.fp.o, but the
image for EC2 might be as I would expect that to be aimed at Just
Enough OS but then I'm not sure how stripped down they've tried to
make it.
Peter
6:37 p.m.
Peter Robinson wrote:
On Mon, Oct 25, 2010 at 11:52 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Mon, 2010-10-25 at 17:55 -0400, Bill Nottingham wrote:
>> Colin Walters (walters(a)verbum.org) said:
>>> On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters <walters(a)verbum.org>
wrote:
>>>> Unfortunately we didn't notice this dependency until pretty late in
>>>> F14...I'm not sure what can be done reasonably at this point, since
>>>> all of these packages are critical path.
>>> Though I will say that if this was determined to be a blocker, here's
>>> a really safe minimal fix:
>> AFAIK, there's nothing on the release criteria which make this a blocker.
>> You can submit an update whenever for it, of course.
> It's worth pointing out that we're not religious about the criteria: we
> want to have criteria to cover each blocker issue, but that doesn't mean
> that no issue can ever be a blocker unless it meets the existing
> criteria. When we come across an issue that is widely agreed ought to be
> a blocker, but doesn't meet the existing criteria, we write a new
> criterion. :)
>
> Having said that, I don't think this seems serious enough to be a
> blocker, though obviously we'd like the minimal install to be as minimal
> as possible. Does it cause major problems for any spins? I doubt it, I
> expect most of them will have cairo for one reason or another anyway.
I wouldn't expect it to affect the usual spins on s.fp.o, but the
image for EC2 might be as I would expect that to be aimed at Just
Enough OS but then I'm not sure how stripped down they've tried to
make it.
While we (the Cloud SIG) are shooting for a very minimal EC2 image, last
I heard we still planned to ship it with SELinux. But if that isn't the
case then I'm pretty sure this will impact the size of the images we
need to upload.
8:42 p.m.
On Mon, Oct 25, 2010 at 15:52:38 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
Having said that, I don't think this seems serious enough to be a
blocker, though obviously we'd like the minimal install to be as minimal
as possible. Does it cause major problems for any spins? I doubt it, I
expect most of them will have cairo for one reason or another anyway.
At this point the spins ar all smaller than their target size. I expect
that Desktop would have pulled this stuff in, in any case. So it wouldn't
have saved us from the scramble to get it under size.
For custom spins built from the release, an update should be sufficient.
2:31 a.m.
On 10/26/2010 04:22 AM, Adam Williamson wrote:
Having said that, I don't think this seems serious enough to be a
blocker, though obviously we'd like the minimal install to be as minimal
as possible. Does it cause major problems for any spins? I doubt it, I
expect most of them will have cairo for one reason or another anyway.
Can we make this such issues a blocker starting from the next release?
A minimal install should really be minimal. Otherwise, we have failed
and it does affect EC2 deployments among other things.
Rahul
12:42 a.m.
On Tue, 2010-10-26 at 13:01 +0530, Rahul Sundaram wrote:
On 10/26/2010 04:22 AM, Adam Williamson wrote:
>
> Having said that, I don't think this seems serious enough to be a
> blocker, though obviously we'd like the minimal install to be as minimal
> as possible. Does it cause major problems for any spins? I doubt it, I
> expect most of them will have cairo for one reason or another anyway.
Can we make this such issues a blocker starting from the next release?
A minimal install should really be minimal. Otherwise, we have failed
and it does affect EC2 deployments among other things.
it's a bit of a tricky line to draw. We have a size test that makes sure
builds aren't over the targeted sizes, we could add a test that a
minimal install doesn't go over a given size after installation, I
guess. What size would be the target?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:44 a.m.
On 10/27/2010 11:12 AM, Adam Williamson wrote:
it's a bit of a tricky line to draw. We have a size test that
makes sure
builds aren't over the targeted sizes, we could add a test that a
minimal install doesn't go over a given size after installation, I
guess. What size would be the target?
For a minimal install, we can have a explicit list of packages and check
to make sure anything else that it drags in is intentional. Have that a
release criteria.
Rahul
4990
days inactive
4992
days old
10 comments
8 participants
participants (8)
-
Adam Williamson -
Bill Nottingham -
Bruno Wolff III -
Colin Walters -
Dave Jones -
Garrett Holmstrom -
Peter Robinson -
Rahul Sundaram