On Thu, 2006-12-21 at 12:13 -0500, Fernando Nasser wrote:
Rex Dieter wrote:
> Fernando Nasser wrote:
>> I have two questions:
>> 1) If this is a problem that only affects yum and all the other
>> depsolvers do it efficiently, would it be better to fix yum instead or
>> working around it by spec file changes?
> It's still generally a good idea to minimize file deps.
Actually, what's happening is that all depsolvers have the ability to
optimize two time consuming steps if the file deps follow these
guidelines. The two steps are 1) downloading filelist.xml.gz and 2)
parsing filelist.xml to find the package which provides the file deps.
[And this problem is multiplied the more repositories you have defined
as the depsolver will have to grab the filelist.xml file from multiple
Panu points out that only yum currently optimizes this but there's
nothing stopping the others doing it as well.
Sure, but there are cases where it is desirable. I am afraid a dull
guideline will put a straight jacket on developers.
For instance, I know a couple of folks working on a software that in the
current release needs two independent packages. Another developer needs
one (a single one) file from them, but the file may change places. They
thought of adding a virtual provides, but it seems overkill in this case
and it is probably only temporary (which would mean we would use a name
unnecessarily and regret later). So the best way around it was to
require the file, at least until the set of packages stabilize on a
future version of the dependency.
Perhaps a "recommendation" guideline? (if there is such a thing)
Yes. This proposal is for a "Should" rather than a "Must"
In the case you outline, I'd like to see the package depend on the file
until it was settled which package would provide it. Then the
dependency could be converted to a package dep instead. We don't
currently have an ongoing QA requirement, though, so remembering to make
the change would largely be the responsibility of the packager.
>> 2) If we still use file deps for things in /bin /sbin
>> /usr/sbin, which happens for all GCJ compiled packages, wouldn't it
>> force the reading of the second file anyways?
> No, just for items *outside* of those locations does yum need extra
> processing. That's the whole point of this exercise.
Ah, thanks for the clarification. The use of file deps prevents an
optimization to kick in.
Is this list complete: /bin /sbin /usr/bin /usr/sbin ?
Or there are others that do not cause the loading of the second file?
/etc is the other one.
That's why the guideline applies to file deps outside
of /etc /bin /sbin /usr/bin and /usr/sbin.