Re: Package updating

[Don Springall]

Exactly my point. You report does not mention that libgcjawt.so.7 for 
package: openoffice.org-core
is required. To my thinking that is incomplete. Why is that one not in your 
deps list ? How is that report created ?

> From: Rahul Sundaram <sundaram(a)redhat.com&gt;
> Reply-To: For testers of Fedora Core development releases 
> <fedora-test-list(a)redhat.com&gt;
> To: For testers of Fedora Core development releases 
> <fedora-test-list(a)redhat.com&gt;
> Subject: Re: Package updating
> Date: Fri, 16 Dec 2005 05:52:14 +0530
>
> Don Springall wrote:
>
> >Try updating all the openoffice packages. What do you get ?
>
> Depends on Tomcat which is specified as a broken dependency.
>
> https://www.redhat.com/archives/fedora-test-list/2005-December/msg00400.html
>
> Status on that
>
> https://www.redhat.com/archives/fedora-test-list/2005-December/msg00401.html
>
> regards
> Rahul
>
> --
> fedora-test-list mailing list
> fedora-test-list(a)redhat.com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list

Package updating

[Rahul Sundaram]

Don Springall wrote:

>  Exactly my point. You report does not mention that libgcjawt.so.7 for
>
>  package: openoffice.org-core
>  is required. To my thinking that is incomplete. Why is that one not in 
>  your deps list ? How is that report created ? 
To my understanding only the first layer of package dependencies are in 
the list.  The dependency list is created by running repoquery from 
yum-utils which is in Fedora Extras. If you have issues with it, file 
bug reports with detailed information in http://bugzilla.redhat.com

regards
Rahul

Package updating

[Jef Spaleta]

On 12/15/05, Don Springall <don_springall(a)hotmail.com&gt; wrote:
>  Exactly my point. You report does not mention that libgcjawt.so.7
> for
>  package: openoffice.org-core
>  is required. To my thinking that is incomplete. Why is that one not in your
>  deps list ? How is that report created ? 
libgcjawt.so.7  exists in the tree and is provided by libgcj. This
isn't the problem. The build report is complete.  You are
misunderstanding the underlying problem and exactly what the build
report details.  Let me attempt to clear it up for you.

Everything that openoffice-org.core package explcitly requires is
provided by another package in rawhide. The problem is actually two
layers deeper, one of the dependant packages,  hsqldb, requires
tomcat5-servlet-2.4-api which has a dependancy problem which is
detailed in the report.

The build report does not attempt to look down the full stack of
dependacies for each packages to see if a specific package will
install.  You can not use the report to answer the question
"Will package foo install without error"
You can answer the question
"Which packages have an explict dependancy problems"
The report details the exact dependancies breakage in the tree, it
doesn't attempt to measure how many packages are affected by that
breakage.. all it does it pinpoint exactly in the tree where there are
problems.

The details of whats going on with openoffice.org-core in rawhide:
openoffice.org-core  in rawhide requires libgcjawt.so.7 and hsqldb >= 1.80.1
libgcjawt.so.7 is provided by libgcj
hsqldb >= 1.80.1 is provided by package hsqldb
pckage hsqldb requires servletapi5
servletapi5 is provided by  tomcat5-servlet-2.4-api
tomcat5-serverlet-2.4-api requires  libgcjawt.so.6
libgcjawt.so.6 is NOT provided in the tree

tomcat5-servlet-2.4-api has a problem, it is not a problem directly related to
the dependancies listed in the openoffice.org-core package.

-jef

Package updating

[Jesse Keating]

On Thu, 2005-12-15 at 20:11 -0500, Jeff Spaleta wrote:
>  The details of whats going on with openoffice.org-core in rawhide:
>  openoffice.org-core  in rawhide requires libgcjawt.so.7 and hsqldb >= 1.80.1
>  libgcjawt.so.7 is provided by libgcj
>  hsqldb >= 1.80.1 is provided by package hsqldb
>  pckage hsqldb requires servletapi5
>  servletapi5 is provided by  tomcat5-servlet-2.4-api
>  tomcat5-serverlet-2.4-api requires  libgcjawt.so.6
>  libgcjawt.so.6 is NOT provided in the tree
>  
>  tomcat5-servlet-2.4-api has a problem, it is not a problem directly related to
>  the dependancies listed in the openoffice.org-core package. 

Tomcat5 successfully built today, so it will be in tomorrows rawhide,
although it looks like a new oo.org will be too, if it ever finishes
building.  Hopefully the two are in sync and you can install them (:

-- 
Jesse Keating
Release Engineer: Fedora

Package updating

[Rahul Sundaram]

Hi

>  You can not use the report to answer the question
> "Will package foo install without error"
> You can answer the question
> "Which packages have an explict dependancy problems"
> The report details the exact dependancies breakage in the tree, it
> doesn't attempt to measure how many packages are affected by that
> breakage.. all it does it pinpoint exactly in the tree where there are
> problems.
>  
I think the problem we are seeing here is the result of people here 
expecting the former while getting the latter. Would it be possible to 
modify repoquery to provide this functionality?

regards
Rahul

Package updating

[Jesse Keating]

On Fri, 2005-12-16 at 07:00 +0530, Rahul Sundaram wrote:
>  I think the problem we are seeing here is the result of people here 
>  expecting the former while getting the latter. Would it be possible to 
>  modify repoquery to provide this functionality? 
While it may be possible, I think the task time would skyrocket.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating

Package updating

[Rahul Sundaram]

Jesse Keating wrote:

> On Fri, 2005-12-16 at 07:00 +0530, Rahul Sundaram wrote:
>   
>
> >I think the problem we are seeing here is the result of people here 
> >expecting the former while getting the latter. Would it be possible to 
> >modify repoquery to provide this functionality?
> >    
> >
>
> While it may be possible, I think the task time would skyrocket.
>
>   
>  
One way to determine this is for someone to code this functionality and 
check out how long it actually takes ( not that I am volunteering). It 
does make it a bit more easier for testers to understand whats broken. 
Alternatively just try and clarify the rawhide report that only the 
first layer of dependencies are included in the list if thats going to 
make any difference.

regards
Rahul

Package updating

[Jef Spaleta]

On 12/15/05, Rahul Sundaram <sundaram(a)redhat.com&gt; wrote:
>  One way to determine this is for someone to code this functionality
> and
>  check out how long it actually takes ( not that I am volunteering). It
>  does make it a bit more easier for testers to understand whats broken. 
I think Panu might be the best person to ask as to whether or you can
have repodata tool ask this question without an egregious calculation
penalty.   Even if it can, I'd be inclined not to include that
information in the build reports, because its highly redudant
information.  One broken dependancy can cascade into dozens of
uninstallable packages... and thats makes for a very long build report
to sift through.

It might be worthwhile to be able to ask "will package foo install"
from a client side tool every once in a while. But I don't see much
value the question "which packages will not install" when the output
list is very long.  How exactly does one use a list of 30+
uninstallable packages.   The best question with regard to testers is
"what is the minimal set of --excludes that I need to use to avoid
install/update dependancy issues?" and I have no idea how one would go
about making a tool that outputs the answer to that.  If there was a
way to answer that without excessive calculation, it would be a
compact and useful expression to add to the rawhide build report.

-jef