1:46 p.m.
Hello,
Last night I had an idea, why not alias "yum update" to "yum
--skip-broken update" by default? This simple hack could prevent a lot
of recurring support questions on the forums:
1) People who have dependency problem won't see them anymore.
2) It doesn't change anything for the rest of the people.
What do you think about that?
Steven
2:09 p.m.
On Thu, 11 Dec 2008, Steven Moix wrote:
Hello,
Last night I had an idea, why not alias "yum update" to "yum
--skip-broken update" by default? This simple hack could prevent a lot
of recurring support questions on the forums:
1) People who have dependency problem won't see them anymore.
b/c we need to get the dep problems reported, too.
2) It doesn't change anything for the rest of the people.
sure it does, it means that you think you're updated completely, but
you're not.
-sv
2:20 p.m.
On Thu, 11 Dec 2008, Bill Nottingham wrote:
Seth Vidal (skvidal(a)fedoraproject.org) said:
>> 1) People who have dependency problem won't see them anymore.
>
> b/c we need to get the dep problems reported, too.
Then you also enable by default the yum-email-dep-problems-to-fedora-devel
plugin.
Do we have an anonymous bug filer account we can use? If so, then,
well,yes, we can do that.
-sv
2:24 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Seth Vidal wrote:
On Thu, 11 Dec 2008, Bill Nottingham wrote:
> Seth Vidal (skvidal(a)fedoraproject.org) said:
>>> 1) People who have dependency problem won't see them anymore.
>>
>> b/c we need to get the dep problems reported, too.
>
> Then you also enable by default the
> yum-email-dep-problems-to-fedora-devel
> plugin.
Do we have an anonymous bug filer account we can use? If so, then,
well,yes, we can do that.
-sv
I would hope that this would be opt-in as well, or we're going to make a
lot of people angry. Some people don't necessarily want to broadcast the
list of packages they have or want on their system - broken or not.
- --
- --------------------
Stephen Gallagher
RHCE 804006346421761
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAklBdvcACgkQeiVVYja6o6PexwCdFCLllW5MtWeAysPiTXjpnNpD
NPgAnRrDzWNDrlVxrRVvsujvHyIykk1E
=obDj
-----END PGP SIGNATURE-----
2:25 p.m.
On Thu, 11 Dec 2008, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Seth Vidal wrote:
>
>
> On Thu, 11 Dec 2008, Bill Nottingham wrote:
>
>> Seth Vidal (skvidal(a)fedoraproject.org) said:
>>>> 1) People who have dependency problem won't see them anymore.
>>>
>>> b/c we need to get the dep problems reported, too.
>>
>> Then you also enable by default the
>> yum-email-dep-problems-to-fedora-devel
>> plugin.
>
> Do we have an anonymous bug filer account we can use? If so, then,
> well,yes, we can do that.
>
> -sv
>
I would hope that this would be opt-in as well, or we're going to make a
lot of people angry. Some people don't necessarily want to broadcast the
list of packages they have or want on their system - broken or not.
What in fedora is NOT opt-in? Moreover, it's a plugin.
-sv
2:29 p.m.
On Thu, Dec 11, 2008 at 3:24 PM, Stephen Gallagher <sgallagh(a)redhat.com>wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Seth Vidal wrote:
>
>
> On Thu, 11 Dec 2008, Bill Nottingham wrote:
>
>> Seth Vidal (skvidal(a)fedoraproject.org) said:
>>>> 1) People who have dependency problem won't see them anymore.
>>>
>>> b/c we need to get the dep problems reported, too.
>>
>> Then you also enable by default the
>> yum-email-dep-problems-to-fedora-devel
>> plugin.
>
> Do we have an anonymous bug filer account we can use? If so, then,
> well,yes, we can do that.
>
> -sv
>
I would hope that this would be opt-in as well, or we're going to make a
lot of people angry. Some people don't necessarily want to broadcast the
list of packages they have or want on their system - broken or not.
Its not really a problem to simply add --skip-broken when something is
broke. But I'd be OK with yum automatically using the --skip-broken
feature, explaining what is broke at the end, then asking if it is ok to
report it anonymously.
--
projecthuh.com
All of my bits are free, are yours? Fedoraproject.org
2:36 p.m.
2008/12/11 Dr. Diesel <dr.diesel(a)gmail.com>:
Its not really a problem to simply add --skip-broken when something
is
broke. But I'd be OK with yum automatically using the --skip-broken
feature, explaining what is broke at the end, then asking if it is ok to
report it anonymously.
That seems like a reasonable trade-off. IF we can set up an anonymous
drop point that we can easily turn off its being abused with spam.
Don't forget to wrap that in UI for PK as well.
-jef
3:01 p.m.
Bill Nottingham wrote:
Seth Vidal (skvidal(a)fedoraproject.org) said:
>> 1) People who have dependency problem won't see them anymore.
> b/c we need to get the dep problems reported, too.
Then you also enable by default the yum-email-dep-problems-to-fedora-devel
plugin.
Bill
Hmmm, I'm not sure exactly what kind of repository information you can
query from a yum plugin, but this plugin would need to be fairly
specific to the fedora repositories and would need to ignore
dep-problems on peoples on-site mirrors and such. Otherwise we'd get a
lot of bugs filed, caused by the use of such repos.
/Thomas
3:07 p.m.
On Thu, 2008-12-11 at 15:09 -0500, Seth Vidal wrote:
On Thu, 11 Dec 2008, Steven Moix wrote:
> Hello,
>
> Last night I had an idea, why not alias "yum update" to "yum
> --skip-broken update" by default? This simple hack could prevent a lot
> of recurring support questions on the forums:
>
> 1) People who have dependency problem won't see them anymore.
b/c we need to get the dep problems reported, too.
> 2) It doesn't change anything for the rest of the people.
>
sure it does, it means that you think you're updated completely, but
you're not.
-sv
Ok, you have a point.
I was suggesting this from a guy-who-reads-user-forums standpoint. The
Fedora update mirrors are often out of sync for 1-3 days, which fills
the forums almost every day with users who don't understand what's going
on when they have dependency problems.
I'm fully aware that this is a dirty hack, but it could solve just that
problem, now there are side effects of course.
Steven
4:28 p.m.
On Thu, 2008-12-11 at 22:07 +0100, Steven Moix wrote:
I was suggesting this from a guy-who-reads-user-forums standpoint.
The
Fedora update mirrors are often out of sync for 1-3 days, which fills
the forums almost every day with users who don't understand what's going
on when they have dependency problems.
My understanding was the MM wanted mirrors to be in sync. within a day,
and as long as the metadata is within sync. it is almost "free" to
switch mirrors to find metadata/packages now (just get 404s and move
along).
I'm fully aware that this is a dirty hack, but it could solve
just that
problem, now there are side effects of course.
To be fair, there is a much less dirty hack of just setting
"skip_broken = true" in yum.conf (it's in the man page :p). And this
might be turned on a some point, but as other people have said before
that happens we really want:
. Lots of checking server side (repoclosure type stuff) to make sure
what we push is good.
. Lots of testing to make sure skip-broken doesn't make the problem
worse (many cases of infinite loops in the past, although it's getting
close now).
--
James Antill <james(a)fedoraproject.org>
Fedora
7:40 p.m.
Seth Vidal wrote:
On Thu, 11 Dec 2008, Steven Moix wrote:
> Hello,
>
> Last night I had an idea, why not alias "yum update" to "yum
> --skip-broken update" by default? This simple hack could prevent a lot
> of recurring support questions on the forums:
>
> 1) People who have dependency problem won't see them anymore.
b/c we need to get the dep problems reported, too.
I'm just wondering why you need 1000s of busy developers to all hit the
same dependency issues to find this out?
Can't you do this on one "dependency checker' machine somewhere? Or
have it automatically reported from a limited number of testers?
--
John Ellson
7:47 p.m.
On Thu, Dec 11, 2008 at 4:40 PM, John Ellson <john.ellson(a)comcast.net> wrote:
Can't you do this on one "dependency checker' machine
somewhere? Or have
it automatically reported from a limited number of testers?
A limited number of testers who attempt to install and update
EVERYTHING from every possible starting state between release and
current update collection.. including 3rd party interactions?
-jef
1:42 p.m.
Jeff Spaleta wrote:
On Thu, Dec 11, 2008 at 4:40 PM, John Ellson
<john.ellson(a)comcast.net> wrote:
> Can't you do this on one "dependency checker' machine somewhere? Or
have
> it automatically reported from a limited number of testers?
>
A limited number of testers who attempt to install and update
EVERYTHING from every possible starting state between release and
current update collection.. including 3rd party interactions?
-jef
How about just within the current Fedora collection?
e.g.
# yum install sysklogd
Resolving Dependencies
--> Running transaction check
---> Package sysklogd.x86_64 0:1.5-3.fc10 set to be updated
--> Processing Conflict: sysklogd conflicts rsyslog
--> Finished Dependency Resolution
sysklogd-1.5-3.fc10.x86_64 from rawhide has depsolving problems
--> sysklogd conflicts with rsyslog
Error: sysklogd conflicts with rsyslog
or the problem that causes "yum install tetex-bytefield tetex-perltex"
to just die without even trying to install them.
(rpm -Uvh ... reports conflicts for these two with texlive)
rpm -Uvh ./rawhide/packages/tetex-bytefield-1.2a-4.fc10.noarch.rpm
./rawhide/packages/tetex-perltex-1.7-1.fc10.noarch.rpm
Preparing...
########################################### [100%]
file /usr/share/texmf/doc/latex/perltex/perltex.pdf from install
of tetex-perltex-1.7-1.fc10.noarch conflicts with file from package
texlive-texmf-doc-2007-26.fc10.noarch
file /usr/share/texmf/tex/latex/perltex/perltex.sty from install
of tetex-perltex-1.7-1.fc10.noarch conflicts with file from package
texlive-texmf-latex-2007-26.fc10.noarch
file /usr/share/texmf/doc/latex/bytefield/bytefield.pdf from
install of tetex-bytefield-1.2a-4.fc10.noarch conflicts with file from
package texlive-texmf-doc-2007-26.fc10.noarch
file /usr/share/texmf/tex/latex/bytefield/bytefield.sty from
install of tetex-bytefield-1.2a-4.fc10.noarch conflicts with file from
package texlive-texmf-latex-2007-26.fc10.noarch
or the similar problem with "sos" ?
rpm -Uvh ./rawhide/packages/sos-1.8-3.fc11.noarch.rpm
Preparing...
########################################### [100%]
file /usr/sbin/sysreport from install of sos-1.8-3.fc11.noarch
conflicts with file from package sysreport-1.4.4-1.noarch
file /usr/share/sysreport/functions from install of
sos-1.8-3.fc11.noarch conflicts with file from package
sysreport-1.4.4-1.noarch
--
John Ellson
2 p.m.
On Fri, 2008-12-12 at 13:56 -0600, Jason L Tibbitts III wrote:
>>>>> "JE" == John Ellson
<john.ellson(a)comcast.net> writes:
JE> How about just within the current Fedora collection?
JE> Error: sysklogd conflicts with rsyslog
I hope you realize that's intentional. The two packages explicitly
conflict.
- J<
Which I do believe is against the packaging guidelines.
We /cannot/ have any 2 current packages in Fedora that conflict with
eachother. That is something I will fight tooth and nail for until the
end of time.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:02 p.m.
>>>> "JK" == Jesse Keating
<jkeating(a)redhat.com> writes:
JK> Which I do believe is against the packaging guidelines.
Not really. Conflicts should be explicit if they exist.
http://fedoraproject.org/wiki/Packaging/Conflicts
"Whenever possible, Fedora packages should avoid conflicting with each
other. Unfortunately, this is not always possible. These guidelines
illustrate how conflicts should be handled in Fedora, specifically
concerning when and when not to use the Conflicts: field."
- J<
2:08 p.m.
On Fri, Dec 12, 2008 at 2:02 PM, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
>>>>> "JK" == Jesse Keating
<jkeating(a)redhat.com> writes:
JK> Which I do believe is against the packaging guidelines.
Not really. Conflicts should be explicit if they exist.
http://fedoraproject.org/wiki/Packaging/Conflicts
"Whenever possible, Fedora packages should avoid conflicting with each
other. Unfortunately, this is not always possible. These guidelines
illustrate how conflicts should be handled in Fedora, specifically
concerning when and when not to use the Conflicts: field."
More importantly, in the next paragraph:
"As a general rule, Fedora packages must NOT contain any usage of the
Conflicts: field."
jerry
--
Store in cool, dry place. Rotate stock.
2:18 p.m.
New subject: Package Conflicts (was Re: yum --skip-broken update by default?)
On Fri, 2008-12-12 at 14:08 -0600, Jerry Amundson wrote:
> http://fedoraproject.org/wiki/Packaging/Conflicts
>
> "Whenever possible, Fedora packages should avoid conflicting with each
> other. Unfortunately, this is not always possible. These guidelines
> illustrate how conflicts should be handled in Fedora, specifically
> concerning when and when not to use the Conflicts: field."
More importantly, in the next paragraph:
"As a general rule, Fedora packages must NOT contain any usage of the
Conflicts: field."
Yeah, I'll go to bat with the FPC on the wording of this rule.
Conflicts are allowed to express that a given package may conflict with
an older version of some other package, but may not directly require
that other package and vice-versa. What I don't find acceptable is any
current Fedora package conflicting with any other current Fedora
package, either explicitly or through files.
The failure case of when this happens is just unacceptable. yum, et al,
cannot tell if files conflict until the packages are all downloaded
first, and when this happens it's just an error, the user is left to
translate, figure out a different course of action, and start over.
Especially bad during initial installs.
We have an alternatives system for when you absolutely cannot find any
other way for two packages to co-exist.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:22 p.m.
New subject: Package Conflicts (was Re: yum --skip-broken update by default?)
On Fri, Dec 12, 2008 at 12:18:05PM -0800, Jesse Keating wrote:
We have an alternatives system for when you absolutely cannot find any
other way for two packages to co-exist.
I agree with what you said, but not with that part. alternatives are for
packages with compatible command-line and compatible functionalities
(though not necessarily the same coverage), not to avoid conflicts.
--
Pat
2:28 p.m.
Jason L Tibbitts III wrote:
>>>>> "JE" == John Ellson
<john.ellson(a)comcast.net> writes:
>>>>>
JE> How about just within the current Fedora collection?
JE> Error: sysklogd conflicts with rsyslog
I hope you realize that's intentional. The two packages explicitly
conflict.
- J<
Why? Thats a dumb way to select features. Make them not-conflict and
provide some kind of configuration option.
Who is going to read the fine print when there 5000 rpms to play with?
Just IMHO
--
John Ellson
2:33 p.m.
>>>> "JE" == John Ellson
<john.ellson(a)comcast.net> writes:
JE> Why? Thats a dumb way to select features. Make them not-conflict
JE> and provide some kind of configuration option.
Because there have been certain difficulties in getting these packages
to live with each other, requiring various finessing which as I
understand things has been progressing.
I mean, come on, two syslog daemons? Each needing to own (and do
things like provide log rotation for) the same files? Alternatives
isn't going to handle that, you know. And as I understand it, there
are actually three syslog daemons people might want to use, all with
the same issues. You make it sound as if these things have absolutely
trivial solutions, and the only reason for making them conflict is to
annoy you. Do you even allow for the possibility that there's an
actual difficult issue here?
- J<
2:40 p.m.
Jason L Tibbitts III wrote:
>>>>> "JE" == John Ellson
<john.ellson(a)comcast.net> writes:
>>>>>
JE> Why? Thats a dumb way to select features. Make them not-conflict
JE> and provide some kind of configuration option.
Because there have been certain difficulties in getting these packages
to live with each other, requiring various finessing which as I
understand things has been progressing.
I mean, come on, two syslog daemons? Each needing to own (and do
things like provide log rotation for) the same files? Alternatives
isn't going to handle that, you know. And as I understand it, there
are actually three syslog daemons people might want to use, all with
the same issues. You make it sound as if these things have absolutely
trivial solutions, and the only reason for making them conflict is to
annoy you. Do you even allow for the possibility that there's an
actual difficult issue here?
- J<
Sure I allow that. But we're off track. My primary complaint is that
this dependency conflict
isn't listed in the daily yum updates dependency list and that yum
doesn't deal with it automatically.
--
John Ellson
2:43 p.m.
On Fri, 12 Dec 2008, John Ellson wrote:
Jason L Tibbitts III wrote:
>>>>>> "JE" == John Ellson <john.ellson(a)comcast.net>
writes:
>>>>>>
>
> JE> Why? Thats a dumb way to select features. Make them not-conflict
> JE> and provide some kind of configuration option.
>
> Because there have been certain difficulties in getting these packages
> to live with each other, requiring various finessing which as I
> understand things has been progressing.
>
> I mean, come on, two syslog daemons? Each needing to own (and do
> things like provide log rotation for) the same files? Alternatives
> isn't going to handle that, you know. And as I understand it, there
> are actually three syslog daemons people might want to use, all with
> the same issues. You make it sound as if these things have absolutely
> trivial solutions, and the only reason for making them conflict is to
> annoy you. Do you even allow for the possibility that there's an
> actual difficult issue here?
>
> - J<
>
>
Sure I allow that. But we're off track. My primary complaint is that this
dependency conflict
isn't listed in the daily yum updates dependency list and that yum doesn't
deal with it automatically.
How would you recommend it be dealt with? And remember we have to have an
acceptable behavior for 'yum -y update'.
When there is a conflict should we:
1. assume the existing pkgs are better
or
2. assume the installing pkgs are better
argument in favor of 1 is that the existing pkgs are on the system and
should therefore be protected as a possible running service.
argument in favor of 2 is that the user is requesting an action and the
user knows best, therefore the requested action must be the 'best' action.
I bet out of 1000 fedora users I'll get an almost even split between them.
-sv
7:13 a.m.
Seth Vidal wrote:
On Fri, 12 Dec 2008, John Ellson wrote:
> My primary complaint is that this dependency conflict
> isn't listed in the daily yum updates dependency list and that yum
> doesn't deal with it automatically.
How would you recommend it be dealt with? And remember we have to have
an acceptable behavior for 'yum -y update'.
When there is a conflict should we:
1. assume the existing pkgs are better
or
2. assume the installing pkgs are better
argument in favor of 1 is that the existing pkgs are on the system and
should therefore be protected as a possible running service.
argument in favor of 2 is that the user is requesting an action and
the user knows best, therefore the requested action must be the 'best'
action.
I bet out of 1000 fedora users I'll get an almost even split between
them.
-sv
I don't think we ask for broken packages to be installed by doing "yum
update". If would be different for "rpm -Uvh --force...."
The currently installed version should never be affected until an
upgrade can be performed without force, error or exceptions.
This is basic transaction semantics. (Where the transaction is not the
entire "yum update", but each independent package dependency subtree).
Anyway, if a package has a conflict, then its not going to install, so
the installed version wins.
Updates are only allowed if all conditions are met, otherwise something
is going on that the packager or the developer didn't foresee, and this
needs
to be reported back to them and fixed. However, unrelated updates
should be allowed to proceed. With ~500M of updates
every day in Rawhide, its not acceptable to block the entire firehose.
Updates should never be forced, because then you have broken dependency
rules or transformations.
As a user, its mostly not very interesting if an update is broken.
Don't bother me with it, just tell the packager to fix it and come back
later.
Occasionally I might be willing to move a few things out of the way
manually to get an update to install, but for me this is the exception.
--
John Ellson
2:29 p.m.
On Fri, Dec 12, 2008 at 10:42 AM, John Ellson <john.ellson(a)comcast.net> wrote:
How about just within the current Fedora collection?
You missed the point.
If we make skip-broken work silently by default and do not notify
users about the crap being skipped... then our users who have 3rd
party repos installs will be missing Fedora updates. That means..
they will silently fail to receive Fedora signed security updates. Not
cool. We can't just turn a blind-eye to that because they have 3rd
party repos enabled if we deliberately choose a default setting which
does that sort of thing silently.
Then there is also crap like locally installed packages..which were
downloaded from outside a repository structure. Poeple do it. We make
it easy for them to do via a url handler in Firefox. There's no bloody
way a team of testers can catch that.
You can not possibly hit all the in the wild cases where someone is
going be affected by a broken dep chain which prevents them from
getting a Fedora signed security update with a small team of testers
who dedicate their very existence to testing for depchain breakage.
We have to notify users as its happening on their systems. I've no
problem giving them a choice to skip once they are notified.. but they
absolutely must be notified that updates are being skipped and whether
those updates are considered security or critical. To silently ignore
that those updates aren't being installed, is a failure to adequately
notify users so they can make informed choices.
-jef
2:42 p.m.
Jeff Spaleta wrote:
On Fri, Dec 12, 2008 at 10:42 AM, John Ellson
<john.ellson(a)comcast.net> wrote:
> How about just within the current Fedora collection?
>
You missed the point.
If we make skip-broken work silently by default and do not notify
users about the crap being skipped...
That would be fine, and notify the
developers too, but then just install
the rest of the updates
without quitting on me.
then our users who have 3rd
party repos installs will be missing Fedora updates. That means..
they will silently fail to receive Fedora signed security updates. Not
cool. We can't just turn a blind-eye to that because they have 3rd
party repos enabled if we deliberately choose a default setting which
does that sort of thing silently.
Then there is also crap like locally installed packages..which were
downloaded from outside a repository structure. Poeple do it. We make
it easy for them to do via a url handler in Firefox. There's no bloody
way a team of testers can catch that.
You can not possibly hit all the in the wild cases where someone is
going be affected by a broken dep chain which prevents them from
getting a Fedora signed security update with a small team of testers
who dedicate their very existence to testing for depchain breakage.
We have to notify users as its happening on their systems. I've no
problem giving them a choice to skip once they are notified.. but they
absolutely must be notified that updates are being skipped and whether
those updates are considered security or critical. To silently ignore
that those updates aren't being installed, is a failure to adequately
notify users so they can make informed choices.
-jef
--
John Ellson
5:26 a.m.
If we make skip-broken work silently by default and do not notify
users about the crap being skipped...
In case no one noticed, skip-broken does notify users about the crap
being skipped now
Granted, this is a bit lost in yum's usual verbosity. But that's not
an argument to no make sckip-broken the default
5:56 a.m.
Nicolas Mailhot wrote:
> If we make skip-broken work silently by default and do not notify
> users about the crap being skipped...
>
In case no one noticed, skip-broken does notify users about the crap
being skipped now
Granted, this is a bit lost in yum's usual verbosity. But that's not
an argument to no make sckip-broken the default
Skipped packages is shown in package confirmation, just like installed,
updated etc. So running yum-cli is not then problem, but pk need to
be able to show skipped packages too.
Tim
2:26 p.m.
2008/12/11 Steven Moix <steven.moix(a)axianet.ch>:
Last night I had an idea, why not alias "yum update" to
"yum
--skip-broken update" by default? This simple hack could prevent a lot
of recurring support questions on the forums:
1) People who have dependency problem won't see them anymore.
2) It doesn't change anything for the rest of the people.
What do you think about that?
Originally thought that as well, but then I saw yum --skip-broken
running into an endless loop with the dependency problems yesterday
(and not reacting well to crtl-c), so maybe this is not a good idea.
- Thomas
2:33 p.m.
On Thu, Dec 11, 2008 at 11:26 AM, Thomas Moschny
<thomas.moschny(a)gmail.com> wrote:
Originally thought that as well, but then I saw yum --skip-broken
running into an endless loop with the dependency problems yesterday
(and not reacting well to crtl-c), so maybe this is not a good idea.
I bug in software to protect you from encountering bugs in other software.....
oh the irony.
-jef
5669
days inactive
5672
days old
30 comments
16 participants
participants (16)
-
Andy Lawrence -
Bill Nottingham -
James Antill -
Jason L Tibbitts III -
Jef Spaleta -
Jerry Amundson -
Jesse Keating -
John Ellson -
Nicolas Mailhot -
Patrice Dumas -
Seth Vidal -
Stephen Gallagher -
Steven Moix -
Thomas M Steenholdt -
Thomas Moschny -
Tim Lauridsen