Just some intro for those who haven't played this game before...
If you've reported a bug, you may have noticed in the past few days that the bug may now be listed as blocking bug 100643 or bug 100644. These bugs are the 'CambridgeBlocker' and 'CambridgeTarget' bugs
What these bugs represent:
- categorization of bugs into relative high and medium priorities
What these bugs don't represent:
- guarantees that the bug will be fixed
Note that these lists are populated at first through cursory bug triage; issues in these bugs may eventually turn out to be NOTABUG or WONTFIX.
How You Can Help (if you so desire):
1) If you've got a bug that appears to be overlooked in this categorization, feel free to nomintate it in the body of the appropriate tracking bug ('CambridgeBlocker', or 'CambridgeTarget'); then our crack (cracked?) bug triage team will review it again.
(Note that all bugs opened against the beta are usually given a once-over within a day or two of being opened; this is how the list normally gets populated)
2) Look at the bugs on the list, and feel free to: - perform duplicate eliminations - verfiy reproducibility/create test cases - provide patches to fix them. (This option is preferred, of course.)
Bugs may be moved from one list to the other at any time, or deescalated completely. The chances of an enhancement requests landing on either of these lists is fairly low.
Bill
On Mon, Jul 28, 2003 at 10:18:54PM -0400, Bill Nottingham wrote:
[much snippage]
Bugs may be moved from one list to the other at any time, or deescalated completely. The chances of an enhancement requests landing on either of these lists is fairly low.
Let me get this straight: - bugs will be triaged and possibly escalated whereas RFEs will not
Does this mean that RFEs simply sit there until they fall off the bottom?
On Tue, Jul 29, 2003 at 11:57:26AM -0700, Jack Bowling wrote:
On Mon, Jul 28, 2003 at 10:18:54PM -0400, Bill Nottingham wrote:
[much snippage]
Bugs may be moved from one list to the other at any time, or deescalated completely. The chances of an enhancement requests landing on either of these lists is fairly low.
Let me get this straight:
- bugs will be triaged and possibly escalated whereas RFEs will not
Does this mean that RFEs simply sit there until they fall off the bottom?
No, RFE's will remain, just like all bugzilla entries.
However, at this point in the release cycle, it's about bugs, not RFE's.
73 de Jeff
Jack Bowling (jbinpg@shaw.ca) said:
Bugs may be moved from one list to the other at any time, or deescalated completely. The chances of an enhancement requests landing on either of these lists is fairly low.
Let me get this straight:
- bugs will be triaged and possibly escalated whereas RFEs will not
Does this mean that RFEs simply sit there until they fall off the bottom?
No, it's just that at this stage in the release, bugs have higher priorities than most RFEs. When you're tracking issues that you want to fix to ship a release, that's mainly bugs as opposed to enhancements.
Bill
On Tue, Jul 29, 2003 at 03:27:28PM -0400, Bill Nottingham wrote:
Jack Bowling (jbinpg@shaw.ca) said:
Bugs may be moved from one list to the other at any time, or deescalated completely. The chances of an enhancement requests landing on either of these lists is fairly low.
Let me get this straight:
- bugs will be triaged and possibly escalated whereas RFEs will not
Does this mean that RFEs simply sit there until they fall off the bottom?
No, it's just that at this stage in the release, bugs have higher priorities than most RFEs. When you're tracking issues that you want to fix to ship a release, that's mainly bugs as opposed to enhancements.
OK, I don't want to be overly argumentative here, but if the releases are now short-cycle, just when will there be enough time to sweep the bugs away and get to the RFEs?
are now short-cycle, just when will there be enough time to sweep the bugs away and get to the RFEs?
Once a release is done is the time RFE's tend to get looked through in detail. Obviously an RFE that reads ".. and I've been maintaining this package on fedora for a year" is a great way to make your RFE popular 8)
Hi,
Are redundant and missing (Build)Requires in src rpm's considered RFE's or should they be reported at this stage? I have assembled a small list that I wanted to check, but I could wait reporting such issues if they are not considered relevant at this stage.
When a (src) rpm contains both a Requires for a file and the rpm providing that file is this considered a redundant Requires?
Bye, Leonard.
-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.
Are redundant and missing (Build)Requires in src rpm's considered RFE's or should they be reported at this stage? I have assembled a
I report them as bugs, especially ones that build different packages as a result. I got burned nastily by xmms not requiring vorbis and producing working, complete functional players that didnt play anything 8)
On Tuesday 29 July 2003 17:35, Alan Cox Alan Cox alan@redhat.com wrote:
are now short-cycle, just when will there be enough time to sweep the bugs away and get to the RFEs?
Once a release is done is the time RFE's tend to get looked through in detail. Obviously an RFE that reads ".. and I've been maintaining this package on fedora for a year" is a great way to make your RFE popular 8)
... *or* "I've been REQUESTING this feature for the last three versions of Red Hat linux" ... would that also grab attention?
Elton ;-)
Hi Alan,
Are redundant and missing (Build)Requires in src rpm's considered RFE's or should they be reported at this stage?
I report them as bugs, especially ones that build different packages as a result.
That answers my question concerning missing (Build)Requires. Tetex src rpm is a possible candidate here.
But what about redundant (Build)Requires? And what about my question what consitutes to a redundant Requires? Fe on RH 7.3
$ rpm -qR XFree86-devel XFree86-libs = 4.2.1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 ld-linux.so.2 libc.so.6 libdl.so.2 libICE.so.6 libSM.so.6 libX11.so.6 libXext.so.6 libXpm.so.4 libXt.so.6 /bin/sh libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3)
But libICE.so.6, libSM.so.6, libX11.so.6, libXext.so.6, libXpm.so.4 and libXt.so.6 are all provided by XFree86-libs = 4.2.1. What is the rationale behind mentioning all the libs specifically? Is this really necessary or should they be considered redundant?
And what about the 4 libc.so.6 entries? What is the value of the extra entries?
Bye, Leonard.
-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.
Hello, On Wed, Jul 30, 2003 at 01:32:14AM +0200, Leonard den Ottolander wrote:
$ rpm -qR XFree86-devel XFree86-libs = 4.2.1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 ld-linux.so.2 libc.so.6 libdl.so.2 libICE.so.6 libSM.so.6 libX11.so.6 libXext.so.6 libXpm.so.4 libXt.so.6 /bin/sh libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3)
But libICE.so.6, libSM.so.6, libX11.so.6, libXext.so.6, libXpm.so.4 and libXt.so.6 are all provided by XFree86-libs = 4.2.1. What is the rationale behind mentioning all the libs specifically? Is this really necessary or should they be considered redundant?
Most requires refering to libraries (as opposed to packages) are generated automatically, which is a Good Thing. It means that the requires are still valid even if XFree86-libs were split into several packages.
And what about the 4 libc.so.6 entries? What is the value of the extra entries?
They require different versioned interfaces, also generated automatically. Mirek
Hi Milo,
Most requires refering to libraries (as opposed to packages) are generated automatically, which is a Good Thing. It means that the requires are still valid even if XFree86-libs were split into several packages.
Right. So I'll concentrate on missing Requires. What about packages that require a lib but don't mention the providing package? Should I consider that a missing Requires then?
Bye, Leonard.
-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.
On Tue, 29 Jul 2003, Jack Bowling wrote:
On Tue, Jul 29, 2003 at 03:27:28PM -0400, Bill Nottingham wrote:
Jack Bowling (jbinpg@shaw.ca) said:
Bugs may be moved from one list to the other at any time, or deescalated completely. The chances of an enhancement requests landing on either of these lists is fairly low.
Let me get this straight:
- bugs will be triaged and possibly escalated whereas RFEs will not
Does this mean that RFEs simply sit there until they fall off the bottom?
No, it's just that at this stage in the release, bugs have higher priorities than most RFEs. When you're tracking issues that you want to fix to ship a release, that's mainly bugs as opposed to enhancements.
OK, I don't want to be overly argumentative here, but if the releases are now short-cycle, just when will there be enough time to sweep the bugs away and get to the RFEs?
As soon as you start creating the patch (-;
Cheers...james
On Tue, 2003-07-29 at 19:54, Leonard den Ottolander wrote:
Hi Milo,
Most requires refering to libraries (as opposed to packages) are generated automatically, which is a Good Thing. It means that the requires are still valid even if XFree86-libs were split into several packages.
Right. So I'll concentrate on missing Requires. What about packages that require a lib but don't mention the providing package? Should I consider that a missing Requires then?
No, it's better when the package ISN'T named, but rather the library only. Read what you quoted above -- "It means that the requires are still valid even if XFree86-libs were split into several packages." What would happen if you put an explicit Requres: XFree86-libs and then down the line, it got split into say, "XFree86-libs" and "XFree86-oldlibs" and the library you need is in "oldlibs" ? Things would not upgrade nicely, because XFree86-oldlibs might not necessarily get installed. But if you just leave the dependency on /usr/X11R6/lib/somelib.so.0 , then you'll be fine if package names change like that.
The automatically generated library dependencies are a Good Thing(tm) IMHO. They certainly aren't causing any problems.
--Jeremy
On Tue, Jul 29, 2003 at 02:30:10PM -0700, Jack Bowling wrote:
OK, I don't want to be overly argumentative here, but if the releases are now short-cycle, just when will there be enough time to sweep the bugs away and get to the RFEs?
Keep in mind that the releases aren't necessarily any shorter-cycle than they've ever been, or shorter than GNOME or Mozilla for example.
The releases are time-based though, that means once the feature freeze hits, all the RFEs are off the list until the next cycle.
This post relating to GNOME is an explanation of how a time-based release works: http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html
Havoc
Hi Jeremy,
No, it's better when the package ISN'T named, but rather the library only.
The automatically generated library dependencies are a Good Thing(tm) IMHO. They certainly aren't causing any problems.
I agree with your argument that the generated library dependencies are useful. But I don't see why *only* the libraries should be named.
On systems lacking a complete package database to query, the explicit naming of the depended on packages would solve the problem of unknown dependencies. Splitting a package and moving a library to a new package would possibly leave a redundant package requirement in a depending on rpm, but the requirement for the library would be still available. If a package maintainer did miss such a library split the redundant package requirement would most probably not harm and be updated as soon as spotted.
Consistently mentioning both the required packages as well as the libraries would make the rpm db system more self-contained and probably solve a lot of dependency problems.
Bye, Leonard.
-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.
Leonard den Ottolander (leonardjo@hetnet.nl) said:
On systems lacking a complete package database to query, the explicit naming of the depended on packages would solve the problem of unknown dependencies.
There are oodles of tools to solve this problem (redhat-config-packages, up2date, yum, ....) Adding extraneous dependencies isn't a solution.
Bill
** Reply to message from Havoc Pennington hp@redhat.com on Tue, 29 Jul 2003 21:00:12 -0400
http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html
On Tue, Jul 29, 2003 at 02:30:10PM -0700, Jack Bowling wrote:
OK, I don't want to be overly argumentative here, but if the releases are now short-cycle, just when will there be enough time to sweep the bugs away and get to the RFEs?
Keep in mind that the releases aren't necessarily any shorter-cycle than they've ever been, or shorter than GNOME or Mozilla for example.
The releases are time-based though, that means once the feature freeze hits, all the RFEs are off the list until the next cycle.
This post relating to GNOME is an explanation of how a time-based release works: http://mail.gnome.org/archives/gnome-hackers/2002-June/msg00041.html
Thanks for the link. Havoc. Although the gist of it may just be enough to send some readers scuttling off to Enterprise and leave WS behind.
jb
-- Jack Bowling Prince George, BC mailto:jbinpg@shaw.ca
Hi Bill,
There are oodles of tools to solve this problem (redhat-config-packages, up2date, yum, ....) Adding extraneous dependencies isn't a solution.
This sounds a bit like putting the cart before the horse. A large part of the problems that people are having with dependencies would be solved if they were able to query the package without requiring an rpmdb or another tool and still get a list of packages to install instead of a list of cryptic library names. (I am not arguing the file dependencies should be dropped.)
The overhead of adding the names of required packages to a package are minimal. It is not very difficult to generate the requirements from the existing requirements. The script below gives an indication of how this could be solved. Or it just adds to the oodles ;).
Anyway, I don't see why we shouldn't use the possibility to specify both files and package names if this makes life easier. Currently the mix of file/library and package name dependencies is a mess anyway.
Bye, Leonard.
$ cat dependencies #!/bin/sh
# dependencies
# This script assembles requirement information for a package # It assumes all dependencies for queried packages are satisfied # This could/should be changed to use an rpmdb instead # # Leonard den Ottolander leonardjo@hetnet.nl, 2003-07-30
# TODO Add package file handling # TODO Add rpmlib version handling
# ${PACK}_requires plain requirements (rpm -qR output) # ${PACK}_requires_sorted sorted requirements (versioning removed) # ${PACK}_requires_libs required library files (.so) # ${PACK}_requires_libstemp temporary list of library packages # ${PACK}_requires_libpacks sorted list of library packages # ${PACK}_requires_execs executables in requirements (contain /) # ${PACK}_requires_execstemp temporary list of executable packages # ${PACK}_requires_execpacks sorted list of executable packages # ${PACK}_requires_rest files other than library and execs # ${PACK}_requires_restlibs specific for rpmlib (why isn't librpm used as a req?) # ${PACK}_requires_restpacks # ${PACK}_requires_packs package names in the original requirements
if [ "$1" == "" ]; then # echo "Usage: $0 <package | package file>" echo "Usage: $0 <package>" exit fi
PACK=$1
#rpm -qf "Package: %{NAME}-%{VERSION}-%{RELEASE}\n" -qR ${PACK} > ${PACK}_requires rpm -qR ${PACK} > ${PACK}_requires cat ${PACK}_requires | cut -f 1 -d \ | cut -f 1 -d ( | sort -u > ${PACK}_requires_sort
# .so is library (also catches absolute library paths) # library search path: (absolute path) /lib /usr/lib . /etc/ld.so.conf grep .so ${PACK}_requires_sort > ${PACK}_requires_libs echo -n '' > ${PACK}_requires_libstemp
for lib in $(cat ${PACK}_requires_libs); do found=0 for path in /lib /usr/lib /usr/local/lib $(cat /etc/ld.so.conf) ; do # maybe library files with explicit paths need special handling # if so, just moving the procedure for files before this should suffice if [ -e $path/$lib ]; then if [ -f $path/$lib ]; then found=1 # or inc and check if > 1 occurence pack=$(rpm -q --whatprovides $path/$lib) retval=$? if [ $retval -eq 0 ]; then echo $pack >> ${PACK}_requires_libstemp else if [ "$pack" == "$(echo $pack | grep not\ owned\ by\ any\ package)" ]; then # echo PACKAGE NOT OWNED # package not owned, follow symlink # ls -l $path/$lib | cut -f 2 -d > | cut -b 2- tlib=$(ls -l $path/$lib | cut -f 2 -d > | cut -b 2-) pack=$(rpm -q --whatprovides $path/$tlib) echo $pack >> ${PACK}_requires_libstemp else # don't know what to do echo "error: $pack" fi fi fi fi done if [ $found -eq 0 ]; then echo "$path/$lib: file not found" fi done
sort -u ${PACK}_requires_libstemp > ${PACK}_requires_libpacks
# executables contain / # / should be first char, or are relative paths allowed? grep / ${PACK}_requires_sort > ${PACK}_requires_execs echo -n '' > ${PACK}_requires_execstemp for file in $(cat ${PACK}_requires_execs) ; do rpm -q --whatprovides $file >> ${PACK}_requires_execstemp done sort -u ${PACK}_requires_execstemp > ${PACK}_requires_execpacks
# no / or . is path nor file thus package name grep -v / ${PACK}_requires_sort | grep -v "." > ${PACK}_requires_rest
# specifically rpmlib (why is this used anyway?) grep lib ${PACK}_requires_rest > ${PACK}_requires_restlibs # how to handle rpmlib further?
# anything else is a package name grep -v lib ${PACK}_requires_rest > ${PACK}_requires_packs
# Sort all requires cat ${PACK}_requires_execpacks > ${PACK}_requires_alltemp cat ${PACK}_requires_libpacks >> ${PACK}_requires_alltemp sort -u ${PACK}_requires_alltemp > ${PACK}_requires_alltemp1
# Produce some output rpm --queryformat "Package %{NAME}-%{VERSION}-%{RELEASE} Requires the following packages:\n" -q ${PACK} #rpm -q ${PACK} cat ${PACK}_requires_alltemp1 | rev | cut -f 2- -d - | sed 's/-/ => /' | rev echo cat ${PACK}_requires_packs
-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 30 Jul 2003 03:41:09 +0200, Leonard den Ottolander wrote:
On systems lacking a complete package database to query, the explicit naming of the depended on packages would solve the problem of unknown dependencies. Splitting a package and moving a library to a new package would possibly leave a redundant package requirement in a depending on rpm, but the requirement for the library would be still available. If a package maintainer did miss such a library split the redundant package requirement would most probably not harm and be updated as soon as spotted.
Consistently mentioning both the required packages as well as the libraries would make the rpm db system more self-contained and probably solve a lot of dependency problems.
For some packages such a list of explicit requirements can get pretty long and would require an extra maintenance effort. For instance, not only when depending packages are renamed or when the dependencies of a package change (user would install redundant stuff). But also when a particular version of a library is found only in a particular package revision. We should rely on tools which solve the dependencies for us and which find out what package to install to get libfoo.so.3.
On systems lacking a complete package database to query,
... there should be an alternative way like querying a remote package database server.
- --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 30 Jul 2003 09:54:30 +0200, Leonard den Ottolander wrote:
Hi Bill,
There are oodles of tools to solve this problem (redhat-config-packages, up2date, yum, ....) Adding extraneous dependencies isn't a solution.
This sounds a bit like putting the cart before the horse. A large part of the problems that people are having with dependencies would be solved if they were able to query the package without requiring an rpmdb or another tool and still get a list of packages to install instead of a list of cryptic library names. (I am not arguing the file dependencies should be dropped.)
For several distributions that use RPM, it started like this, explicit "Requires: ". And still, some users complained about "dependency hell". The reason was simply that in case of a long dependency chain, you end up with a long list of packages to install manually. Who really wants that?
Now as soon as you start using small helper scripts to traverse the dependency tree and collect explicit package names, this is becoming messy. Just observe, that you need physical access to all missing packages in order to solve dependencies (the complete rpmdb takes less space). You don't want to include the complete dependency chain in every individual package, do you? So, why not go one step further and do the real thing? That is, upon package installation, let RPM and package tool front-ends solve the dependency chain automatically by querying an rpmdb and possibly network servers?
As a side-note, RPM cannot know that program X from package Y is executed in script A from package B. Hence in some cases, explicitly listed requirements are likely to stay.
- --
On Wed, 2003-07-30 at 06:52, Michael Schwendt wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 30 Jul 2003 03:41:09 +0200, Leonard den Ottolander wrote:
On systems lacking a complete package database to query, the explicit naming of the depended on packages would solve the problem of unknown dependencies. Splitting a package and moving a library to a new package would possibly leave a redundant package requirement in a depending on rpm, but the requirement for the library would be still available. If a package maintainer did miss such a library split the redundant package requirement would most probably not harm and be updated as soon as spotted.
Consistently mentioning both the required packages as well as the libraries would make the rpm db system more self-contained and probably solve a lot of dependency problems.
For some packages such a list of explicit requirements can get pretty long and would require an extra maintenance effort. For instance, not only when depending packages are renamed or when the dependencies of a package change (user would install redundant stuff). But also when a particular version of a library is found only in a particular package revision. We should rely on tools which solve the dependencies for us and which find out what package to install to get libfoo.so.3.
On systems lacking a complete package database to query,
... there should be an alternative way like querying a remote package database server.
And that is effectively how dependency-solving tools like up2date, apt, yum, etc. work... by querying remote servers, caching appropriate meta-deta locally, and figuring out all of this for you. Leonard: why won't you use one of those tools and thus avoid this whole problem?
--Jeremy
On Tue, Jul 29, 2003 at 06:17:30PM -0400, Elton Woo wrote:
On Tuesday 29 July 2003 17:35, Alan Cox Alan Cox alan@redhat.com wrote:
Once a release is done is the time RFE's tend to get looked through in detail. Obviously an RFE that reads ".. and I've been maintaining this package on fedora for a year" is a great way to make your RFE popular 8)
... *or* "I've been REQUESTING this feature for the last three versions of Red Hat linux" ... would that also grab attention?
No, not really -- there are feature requests that some people have made for the past three *years* (or more) that aren't there for a variety of reasons that don't go away just because of the passing of time and of releases.
The open development process doesn't mean that Red Hat starts taking on loads more work -- we have already had lots of opportunities to collect feedback on requests for features, and the purpose of this project is not to collect more requests for features. Rather, it is to allow some like-minded developers and other community members to influence what is going on by contributing to the process. Don't get me wrong, a request is still a contribution to the process, but that part of the process has not changed from what we did before. Practically speaking, maintaining a package in fedora, as Alan suggests, is a really good first step and will make an RFE more popular, and is fundamentally different from a request.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Wednesday 30 July 2003 10:36, Michael K. Johnson "Michael K. Johnson" johnsonm@redhat.com wrote:
On Tue, Jul 29, 2003 at 06:17:30PM -0400, Elton Woo wrote:
... *or* "I've been REQUESTING this feature for the last three versions of Red Hat linux" ... would that also grab attention?
No, not really -- there are feature requests that some people have made for the past three *years* (or more) that aren't there for a variety of reasons that don't go away just because of the passing of time and of releases.
To be more specific: I've been requesting that my USB scanner be automatically preconfigured ... *for the past three releases*. IMVHO, since Red Hat is aiming to be more "user friendly" isn't this a _reasonable_ request?
Each time I have to manually edit /etc/sane.d/epson.conf. The contents of the *default* file follows: ---------------------------------------------------------------------------------- # epson.conf # # here are some examples for how to configure the EPSON backend # # SCSI scanner: scsi EPSON # # Parallel port scanner: #pio 0x278 #pio 0x378 #pio 0x3BC # # USB scanner - only enable this if you have an EPSON scanner. It could # otherwise block your non-EPSON scanner from being # recognized. # Depending on your distribution, you may need either the # first or the second entry. #usb /dev/usb/scanner0 #usb /dev/usb/scanner0 -----------------------------------------------------------------------------
NOTE: I cannot, for the life of me, see any difference between the two last lines of this configuration file, which has been thus for several past versions, and still remains in the present.
Elton ;-)
On Wed, Jul 30, 2003 at 01:42:32PM -0400, Elton Woo wrote:
To be more specific: I've been requesting that my USB scanner be automatically preconfigured ... *for the past three releases*. IMVHO, since Red Hat is aiming to be more "user friendly" isn't this a _reasonable_ request?
Perfectly reasonable. But it needs a good deal of vendor-specific, scanner-specific, and backend-specific knowledge to work. :-(
Tim. */
Hello Michael,
The reason was simply that in case of a long dependency chain, you end up with a long list of packages to install manually. Who really wants that?
In such cases it would probably be easiest to indeed use an update tool. But many cases are not that complicated. If I wanted to add a package to an installed system most of the time it would only have one or two depdencies in which case I could just pop in the cd or take the needed packages from my update directory. No need to go online and/or use an update tool.
Now as soon as you start using small helper scripts to traverse the dependency tree and collect explicit package names, this is becoming messy. Just observe, that you need physical access to all missing packages in order to solve dependencies (the complete rpmdb takes less space).
The script I added was just to show how simple it would be to generate these requirements. If it were modified to be used as an update tool of course it should use the rpmdb. But that's a different thing.
You don't want to include the complete dependency chain in every individual package, do you?
No.
In most cases the dependecy chain is about 3, 4, 5 items long. Since one builds from the base, on most installed system 2, 3 chains are allready satisfied.
So, why not go one step further and do the real thing? That is, upon package installation, let RPM and package tool front-ends solve the dependency chain automatically by querying an rpmdb and possibly network servers?
As argued above, in many cases one wouldn't need to use such a tool. I am not disputing the usefulness of update tools in certain instances, but I do not need a cannon to kill a mosquito.
As a side-note, RPM cannot know that program X from package Y is executed in script A from package B. Hence in some cases, explicitly listed requirements are likely to stay.
? This argument I don't understand. This is what the requirements are used for, but it doesn't matter whether files or packages are mentioned as requirements. ALso not sure if you mean package or file names with "explicitly listed arguments".
Currently both file and package dependecies are mixed. So it's definitely not the case that all needed files are always explicitely mentioned. Nobody has yet explained to me why there are still packages depending on packages anyway.
For now I stick to mho that also adding package names to the Requires is good for clarity (educational), helps people solve many of the less complicated dependency problems without having to rely on update tools, and is cheap both in package size and maintainance cost.
Bye, Leonard.
-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.
Hello Michael,
For some packages such a list of explicit requirements can get pretty long and would require an extra maintenance effort. For instance, not only when depending packages are renamed or when the dependencies of a package change (user would install redundant stuff).
Firstly, this splitting up or renaming of packages is a seldom occassion. That already significantly reduces the maintainance cost.
There are two cases in which Requires would change: 1) The package gets split up and the depended on file is moved to the new package. (If it is left in the old part nothing changes.) A Requires for the new package needs to be added, but this is obvious and the maintainer can solve this by once querying the rpmdb. After adding the new Requires the maintainer should delete the redundant package requirement. This should be obvious since the maintainer was prompted by the fact that (s)he needed to add a new Requires. But even if missed this can be repaired as soon as spotted. Maybe a redundant package gets installed, but in most cases it is probably required anyway. 2) The package is renamed. A Requires for the new name needs to be added, and since the old name no longer exists the old name needs to be removed. The fact that both steps need to be performed can't be missed (unsatisfied and unsatisfiable Requires respectively).
But also when a particular version of a library is found only in a particular package revision. We should rely on tools which solve the dependencies for us and which find out what package to install to get libfoo.so.3.
One can use version requirements for package names.
Bye, Leonard.
-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.
Hi Jeremy,
And that is effectively how dependency-solving tools like up2date, apt, yum, etc. work... by querying remote servers, caching appropriate meta-deta locally, and figuring out all of this for you. Leonard: why won't you use one of those tools and thus avoid this whole problem?
In many cases one wouldn't need to use these tools if dependencies were clear (as in (also) using package names). For more difficult situations one would use an update tool. See my other posts.
Bye, Leonard.
-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.
On Wed, Jul 30, 2003 at 08:22:26PM +0200, Leonard den Ottolander wrote:
Hi Jeremy,
And that is effectively how dependency-solving tools like up2date, apt, yum, etc. work... by querying remote servers, caching appropriate meta-deta locally, and figuring out all of this for you. Leonard: why won't you use one of those tools and thus avoid this whole problem?
In many cases one wouldn't need to use these tools if dependencies were clear (as in (also) using package names). For more difficult situations one would use an update tool. See my other posts.
Before we set off redesigning package dependency chains for rpm, duplicating existing file and soname dependencies with package dependencies, let me point out --aid, which is quite useful even if you insist on not using tools but prefer manually upgrading using rpm.
0) Mount a distro universe of packages someplace. I use, say, /10/i386 for the RHLP beta.
1) Install the rpmdb-redhat package from that distro.
2) Edit /etc/rpm/macros.solve to configure where to get packages from:
# The path to the dependency universe database. The default value # is the rpmdb-redhat location. The macro is usually defined in # /etc/rpm/macros.solve, installed with the rpmdb-redhat package. %_solve_dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat
# The path to the dependency universe packages. This should # be a path to the packages contained in the solve database. -%_solve_pkgsdir /mnt/redhat/test/latest-i386/RedHat/RPMS/ +%_solve_pkgsdir /10/i386/
# The output binary package file name template used when suggesting # binary packages that solve a dependency. The macro is usually defined # in /etc/rpm/macros.solve, installed with the rpmdb-redhat package. # # XXX Note: escaped %% for use in headerSprintf() -%_solve_name_fmt %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm +%_solve_name_fmt %{?_solve_pkgsdir}%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
3) Add --aid when installing/upgrading a package.
Additional packages will be looked up in the rpmdb-redhat package, the location of the package will be generated by prefixing "/10/i386/", and the package will be automagically added to the transaction.
This solves most of "dependency hell", i.e. chasing down which package satisfies a new dependency quite well.
And, if for some reason you can't afford to make all the packages available at /10/i386 (or wherever), the rpm will display suggested resolutions using rpmdb-redhat.
Yes, tools like up2date and yum do a better job than --aid.
There is no such thing as "clear dependencies", but that's just my opinion.
No matter what, attempting to follow dependency chains manually is not necessary anymore, and adding Yet More package dependency is silly.
73 de Jeff
On Wed, Jul 30, 2003 at 01:42:32PM -0400, Elton Woo wrote:
To be more specific: I've been requesting that my USB scanner be automatically preconfigured ... *for the past three releases*. IMVHO, since Red Hat is aiming to be more "user friendly" isn't this a _reasonable_ request?
No knowledge of this specific bug, but the binary toggle "reasonable" vs. "not reasonable" isn't the right way to think about it.
There are two things that matter:
- the position of each request in developer's priority queue - how many developers there are that have priority queues
To improve this, as a project including non-Red-Hat people we can do two things:
- have more developers and thus more queues, by letting more people contribute - improve the priority queue; for example via the bugzilla methods I posted
Havoc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 30 Jul 2003 20:22:26 +0200, Leonard den Ottolander wrote:
As a side-note, RPM cannot know that program X from package Y is executed in script A from package B. Hence in some cases, explicitly listed requirements are likely to stay.
? This argument I don't understand. This is what the requirements are used for, but it doesn't matter whether files or packages are mentioned as requirements. ALso not sure if you mean package or file names with "explicitly listed arguments".
It is one of the reasons why you see a mixture of automatically generated dependencies and manually added requirements.
Nobody has yet explained to me why there are still packages depending on packages anyway.
Because one package needs the contents or file-structure provided by another package.
For now I stick to mho that also adding package names to the Requires is good for clarity (educational), helps people solve many of the less complicated dependency problems without having to rely on update tools, and is cheap both in package size and maintainance cost.
As has been pointed out before, manually added dependencies increase the package maintenance costs. It gets even worse when you introduce versioned dependencies.
- --
On Wed, Jul 30, 2003 at 10:10:56PM +0200, Michael Schwendt wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 30 Jul 2003 20:22:26 +0200, Leonard den Ottolander wrote:
As a side-note, RPM cannot know that program X from package Y is executed in script A from package B. Hence in some cases, explicitly listed requirements are likely to stay.
? This argument I don't understand. This is what the requirements are used for, but it doesn't matter whether files or packages are mentioned as requirements. ALso not sure if you mean package or file names with "explicitly listed arguments".
It is one of the reasons why you see a mixture of automatically generated dependencies and manually added requirements.
With rpmdb-redhat package in your system you will see the names of packages instead of names of required libraries. There is no reason to file up manually any dependencies when they could be generated automagically (via ldd or so, check /usr/lib/rpm/find-requires).
The only reason to fill Requires: manually (and probably with name of other package) is when this automated process can't be done. This is why rhgb need initscripts with version at least X.Y.Z because when you would like to see graphical boot (provided by rhgb) you have to have initscripts with a line calling rhgb (older initscripts have no similar call).
Hello Michael,
Nobody has yet explained to me why there are still packages depending on packages anyway.
Because one package needs the contents or file-structure provided by another package.
Right. Dumb question ;).
As has been pointed out before, manually added dependencies increase the package maintenance costs.
Well, I guess that is a matter of opinion as I tried to explain.
It gets even worse when you introduce versioned dependencies.
Not really if you use >= . The version only changes if explicit functionality changes and that would show in the required lib/executable anyway.
It seems I am fighting a lost battle. I guess I'll retreat to my tent :).
Bye, Leonard.
-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 30 Jul 2003 22:52:46 +0200, Milan Kerslager wrote:
It is one of the reasons why you see a mixture of automatically generated dependencies and manually added requirements.
With rpmdb-redhat package in your system you will see the names of packages instead of names of required libraries.
I referred to the spec file level, not the RPM user-interface. :)
Btw, rpmdb-redhat is mandatory, IMO.
- --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 30 Jul 2003 22:57:51 +0200, Leonard den Ottolander wrote:
As has been pointed out before, manually added dependencies increase the package maintenance costs.
Well, I guess that is a matter of opinion as I tried to explain.
It gets even worse when you introduce versioned dependencies.
Not really if you use >= .
Those are even harder to find out. ;)
- --
On Wednesday 30 July 2003 15:12, Havoc Pennington Havoc Pennington hp@redhat.com wrote:
On Wed, Jul 30, 2003 at 01:42:32PM -0400, Elton Woo wrote:
To be more specific: I've been requesting that my USB scanner be automatically preconfigured ... *for the past three releases*. IMVHO, since Red Hat is aiming to be more "user friendly" isn't this a _reasonable_ request?
No knowledge of this specific bug, but the binary toggle "reasonable" vs. "not reasonable" isn't the right way to think about it.
Here's the RFE: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=101074.
There are two things that matter:
- the position of each request in developer's priority queue
- how many developers there are that have priority queues
To improve this, as a project including non-Red-Hat people we can do two things:
- have more developers and thus more queues, by letting more people contribute
- improve the priority queue; for example via the bugzilla methods I posted
Havoc
... and somewhat related to that RFE: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=85016 Mandrake linux, AFAIK, has had both these features for some time now. I'm no programmer, so I cannot argue the difficulty or ease of implemeting this in Red Hat's distro.
Elton ;-)
On Wed, 30 Jul 2003, Milan Kerslager wrote:
On Wed, Jul 30, 2003 at 10:10:56PM +0200, Michael Schwendt wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 30 Jul 2003 20:22:26 +0200, Leonard den Ottolander wrote:
As a side-note, RPM cannot know that program X from package Y is executed in script A from package B. Hence in some cases, explicitly listed requirements are likely to stay.
? This argument I don't understand. This is what the requirements are used for, but it doesn't matter whether files or packages are mentioned as requirements. ALso not sure if you mean package or file names with "explicitly listed arguments".
It is one of the reasons why you see a mixture of automatically generated dependencies and manually added requirements.
With rpmdb-redhat package in your system you will see the names of packages instead of names of required libraries. [...]
Using --redhatrequires and --redhatprovides, of course; it's not automatic. (Which may or may not be causing some confusion here..)
Pekka Savola writes:
On Wed, 30 Jul 2003, Milan Kerslager wrote:
With rpmdb-redhat package in your system you will see the names of packages instead of names of required libraries. [...]
Using --redhatrequires and --redhatprovides, of course; it's not automatic. (Which may or may not be causing some confusion here..)
It is automatic for me. I.e., if I try to install a package for which not all requirements are fulfilled, it will first print what is missing, and then suggest the packages which will fulfill these requirements.
-
Alan Cox -
Bill Nottingham -
Elton Woo -
Göran Uddeborg -
Havoc Pennington -
Jack Bowling -
James Olin Oden -
Jeff Johnson -
Jeremy Portzer -
Leonard den Ottolander -
Michael K. Johnson -
Michael Schwendt -
Milan Kerslager -
Miloslav Trmač -
Pekka Savola -
Tim Waugh