Re: If *-module depends on *-utils, should *-source recommend it?
Scott James Remnant [EMAIL PROTECTED] writes: On Tue, 2005-01-11 at 19:30 +0100, Eduard Bloch wrote: * Scott James Remnant [Tue, Jan 11 2005, 08:19:21AM]: dpkg complains that foo-utils is not installed and aborts the installation of foo-modules_2.0 dpkg does not abort the installation, the installation concludes with the package in an unpacked state. If it had aborted the installation it would have unwound various steps. Nitpicking. Precision. We're talking about a (relatively) complex process with many variables used in a wide variety of situations. Sure, we can wave our hands about and say dpkg installs shit, make it do it differently but then we wouldn't get anywhere. If one is proposing a change in dpkg's behaviour, it helps to be fluent in its existing behaviour, precise about the exact way one wishes to change it and knowledgeable about the repercussions of doing so. Why cannot you just admit that dpkg lets the package (*) in an unuseable state at this point? By unuseable, I mean unuseable (**) and not some special state flag written in dpkg's database that means nothing when the day ends. *: as software, I mean files in the file system on their target location, not some theory definition of package within the packagement system **: for user that use it, read: the package contents on the filesystem I think you mean unusable, actually. That's not nitpicking either, that's pure pedantry. Actually, this vastly depends on the package, but yes, in general an unpacked-but-not-configured package is not yet usable. And nor should it be. I think the reversed order is correct and the current order is not - but that's based only on my limited understanding. Is there a reason that the data.tar.gz needs to be unpacked before the dependencies are checked to see if the package can be installed? dpkg -i banana_2.0.all.deb icecream_1.0.all.deb (or 1,000-package equivalents given from APT or dselect which may include quite convoluted conflict and replacement scenarios.) But to do this you need to know what to install and this can only be done by looking at the package metadata and getting the dependencies manualy. You didn't put much thought into that, did you? Make icecream depend on banana, while banana still depends on icecream. With your proposal, dpkg can't unpack either because neither dependency is satisfied. Sure it can, dpkg --unpack just keeps on working. It can't install them and it already shouldn't. Sorry but you started being pedantic. The only reason why it actualy can install them is that dpkg ignores some somewhat random Depends in cycles to break them. The same cycle breaking can apply when testing before the unpack as dpkg uses after the unpacking. Of course this is the right way to do, but sometimes users are lazy (or just expect different things, and some of them appear here, with their arrogant attitude, pissed and beeing polemic). Actually users will be more likely using APT, which worries about this kind of thing all the time. apt also just breaks cycles at some point and it actually does screw up and fails quite often when doing larger updates. See the BTS for such cases in apt. Why cannot you just admit that dpkg sucks on this issue because there are really no sanity checks before potential damage can be done? There's a general assumption that if you install a package, you kinda want it installed. I actually think dpkg's design is reasonably elegant in that it saves you having to repeat a step that failed last time. Doing the 'can this be configured after unpacking' check before unpacking would mean you haven't yet unpacked anything. You would not repeat any step. You only get the resulting error before dpkg does the first step of a 2 step process instead of after the first step. Whether that is a good thing or not can be argued but if you wan't dpkg to only do step 1, maybe because you don't want to type such a long command line with all debs on it, then you can always use --unpack first and --configure -a later. IMO it would be quite simple to work around that - do not overwrite existing files when you extract the tarball. Instead, write them to temporary locations, and move them to the right locations after all checks are done (or /dev/null when something failed). That's the installation equivalent of masturbation, fun but entirely pointless. I agree that this isn't a good idea but for completly different reasons. Unpacking packages to a temp location first would greately increase the disk usage during updates and many system (all of mine) probably don't have that much spare space lying around. Imagine a woody-sarge update where all debs are first unpacked to temp files, all 3GB of your installed debs. If you didn't want the package to be unpacked before its dependencies are installed, you'd just check the dependencies before unpacking. How do you
Re: If *-module depends on *-utils, should *-source recommend it?
On Sat, Jan 15, 2005 at 08:40:56AM +0100, Goswin von Brederlow wrote: Afaik neither debootstrap, cdebootstrap nor rootstrap use dpkg -i to partially install packages. They explicitly use --unpack and --configure and use --force-* options to exactly say what they need. rootstrap doesn't install any packages with dpkg at all, in fact; it only invokes debootstrap and apt-get. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
Scripsit Bernhard R. Link [EMAIL PROTECTED] The elegance is that dpkg is robust in that it can always install everything and can get cleanly from one state to another. However broken the packages are you never end in a sitation you cannot fix again. How would this property be lost if dpkg's default was check for consistency of the end result before it starts unpacking things? Without some full formalisation or anything else to make sure it cannot get out of this state, or can get back to that state easily, it is only a hack. Nobody claims what such checking will necessarily solve all of the world's problems. But it will make life easier for people who only use dpkg occasionally to install locally-built .debs. It would also break serialisation, as one would need to give a list of packages to install to dpkg all at once or in the correct serialisation, and no longer (with exception of configure cycles) beeing able to give them in whatever sequence as one is pleased to do. Nobody is suggesting that there should not be an option to override the default check for users (or front ends) who know what they are doing. -- Henning Makholm That's okay. I'm hoping to convince the millions of open-minded people like Hrunkner Unnerby. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Thu, 2005-01-13 at 17:06 +, Darren Salt wrote: I demand that Scott James Remnant may or may not have written... [snip] And a far better solution to the a package on disk needs dependencies solution is for a command-line tool that can grab the dependencies a package needs, not just bitch about them not existing. apt* with an install-from-local-package command or adaptation of the install command? Yes. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: If *-module depends on *-utils, should *-source recommend it?
On Wed, Jan 12, 2005 at 03:06:06PM +, Scott James Remnant wrote: What William Ballard, Cameron Hutchinson and Eduard Bloch are asking for is to remove the difference between Depends and Pre-Depends and make all Depends behave like Pre-Depends. No: I do not want dependencies to be INSTALLED before unpacking anything. I want them CHECKED: are the dependencies for each package specified on the command line already installed or also specified on the the command line. If so, install out of sequence. If not, stop (by default, unless -forced). It's fair to say this will break other things. Didn't somebody ask for apt to be able to directly install a deb? That would work too. Me, I'm just using temporary apt repositories. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
Steve Langasek [EMAIL PROTECTED] writes: Recommends means packages that would be found together with this one in all but unusual installations. It is not unusual to have a single designated build machine in an organization, which may or may not ever have the final binary packages installed. Depends on how you interpret usual -- if one were to compare a couple of build daemons running on specially hosted boxes in large corporations versus the large number of debian developers along with regular users compiling modules for their personal usage, it would seem the dedicated build machine use /is/ unusual. (This is a bit of speculation though because I don't really know any statistics on common Debian usage especially in businesses.) But even then, it seems like a moot point: if you have a dedicated machine to build alsa-modules for all of your company boxes, will it hurt for it to possibly install alsa-utils as well? AFAIK, a Recommends wouldn't even necessitate alsa-utils installation, and if it *were* to cause any problems the admin could simply mark for it to not install. Why? Installing the -utils package does not make the -source package more or less useful. It only makes the -modules package more useful; until you install the -modules package there isn't actually any use for the -utils package at all. And so you don't have to install the -utils. Not that I can tell, but the root reason people are asking for this functionality is that they want -utils packages to be installed for them automatically when they use -modules packages; when getting the support packages installed is actually quite trivial with even the slightest bit of advanced planning and/or reading of error messages. The real irony is that, with the package in question, automatically pulling in -utils with -source could cause *more* users' systems to break, because the interface between ndiswrapper-utils and ndiswrapper-modules has changed several times recently in ways that were not backwards-compatible: automatically pulling in the -utils could render the system networkless before you've even started to *build* the modules... If a new version of ndiswrapper-utils is not backwards-compatible with an old version of ndiswrapper-modules, shouldn't it declare a versioned Conflicts with those older versions or else when you try to upgrade you'll have problems regardless if ndiswrapper-source declared a Recommends on ndiswrapper-utils? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Wed, Jan 12, 2005 at 10:05:00AM -0600, Matthew Dempsky wrote: Steve Langasek [EMAIL PROTECTED] writes: Recommends means packages that would be found together with this one in all but unusual installations. It is not unusual to have a single designated build machine in an organization, which may or may not ever have the final binary packages installed. Depends on how you interpret usual -- if one were to compare a couple I thought about this. It's definitely not unusual to want to only build it. So Suggest it already :-) An quick glance at various '-source$' packages show some Suggest utils/libs; at least one Recommends them, and some leave them out altogether. I don't feel like looking but it would be interesting to know if the resulting -modules package Depends on them and see if that influenced whether the maintainer Suggested the utils. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
Scripsit Scott James Remnant [EMAIL PROTECTED] Forget the impact on debootstrap, the impact on APT and dselect is pretty huge. dpkg is designed to be able to unpack packages while their dependencies are not yet fulfilled. But don't apt and dselect already invoke dpkg with special options to the effect I'm a front end, I know what I'm doing, just carry out these operations, I take responsibility? What's interesting is nobody has jumped in on this thread to point out that dpkg *has* a dependency field for forcing checking of dependencies before the package is unpacked. Pre-Depends As far as I read the thread, this is not exactly what is being asked. My immediate thought, too, is that it would be sensible for dpkg to start by checking whether all dependencies of the packages it is being asked to install *will* be available after everything is finished, including the case where it is to be installed later in the run. A pre-depends is stronger than that; it asks to have checked that this-and-that dependency is *already* available and configured before the preinst. If given the front-end options dpkg would just omit this check, and unpack and later perhaps fail in the postinst phase. I can certainly accept and anticipate the objection that that would be difficult to implement, and nobody has cared to, but I still don't see why such a behavior would be *wrong*, per se. -- Henning Makholm Feet: Store in a cool dry place -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Wed, 2005-01-12 at 18:28 +, Henning Makholm wrote: Scripsit Scott James Remnant [EMAIL PROTECTED] What's interesting is nobody has jumped in on this thread to point out that dpkg *has* a dependency field for forcing checking of dependencies before the package is unpacked. Pre-Depends As far as I read the thread, this is not exactly what is being asked. My immediate thought, too, is that it would be sensible for dpkg to start by checking whether all dependencies of the packages it is being asked to install *will* be available after everything is finished, dpkg is designed so you don't need to do this. I can certainly accept and anticipate the objection that that would be difficult to implement, and nobody has cared to, but I still don't see why such a behavior would be *wrong*, per se. It's breaking elegance to fix something I'm not convinced is a problem. All of the examples given so far are bogus, there simply isn't a situation I can see where upgrading a package would prevent you from being able to get its dependencies and install them afterwards. And a far better solution to the a package on disk needs dependencies solution is for a command-line tool that can grab the dependencies a package needs, not just bitch about them not existing. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: If *-module depends on *-utils, should *-source recommend it?
On Wed, 2005-01-12 at 12:26 -0800, Daniel Burrows wrote: On Wednesday 12 January 2005 11:52 am, Scott James Remnant wrote: It's breaking elegance to fix something I'm not convinced is a problem. Just to be clear: you mean the elegance of the dpkg code, not its external behavior, right? Because I don't see anything elegant about erroring out and leaving an operation half-completed. Why not? It means that you just need to go fetch and install the dependency, you don't need to try and install the depending package again. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: If *-module depends on *-utils, should *-source recommend it?
On Wednesday 12 January 2005 12:37 pm, Scott James Remnant wrote: On Wed, 2005-01-12 at 12:26 -0800, Daniel Burrows wrote: On Wednesday 12 January 2005 11:52 am, Scott James Remnant wrote: It's breaking elegance to fix something I'm not convinced is a problem. Just to be clear: you mean the elegance of the dpkg code, not its external behavior, right? Because I don't see anything elegant about erroring out and leaving an operation half-completed. Why not? It means that you just need to go fetch and install the dependency, you don't need to try and install the depending package again. Well, you're also leaving the package in a broken and unconfigured state. Doing this in order to save the user a little typing later (adding the original package to the second --install line) seems to me like a hack to make some use cases slightly more convenient, not elegance. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | For a successful technology, reality must take precedence over | | public relations, for nature cannot be fooled. | |-- Richard Feynmann| \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgp5GnMO1s1W2.pgp Description: PGP signature
Re: If *-module depends on *-utils, should *-source recommend it?
On Wed, Jan 12, 2005 at 01:38:28PM -0500, Andres Salomon wrote: Of course. No one has provided proof that this is the case, though. I asked if a versioned depends was necessary, but instead got accusations and vitriol. I have not had time to test it myself yet. Some of the other *-source packages Suggest the utils. Some don't. A couple even Recommends it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Tue, 2005-01-11 at 01:58 -0500, William Ballard wrote: On Tue, Jan 11, 2005 at 06:53:57AM +, Scott James Remnant wrote: On Tue, 2005-01-11 at 01:35 -0500, William Ballard wrote: On Tue, Jan 11, 2005 at 06:16:01AM +, Scott James Remnant wrote: dpkg doesn't remove foo-modules_1.0 at all. Note that I said remove, the old files are replaced during the unpack phase rather than removed. In what sense is banana/foo 1.0 not removed ? It is not removed. Removed, it is not. Not removed, it is. Yoda that any way you like. At no point does dpkg go through the file list of the previous version and remove the files. At no point during the upgrade are you in a state without files of either version on the disk. The files are not removed. As to the rest of your post -- reread this thread more carefully. I have, I'm obviously missing your point. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: If *-module depends on *-utils, should *-source recommend it?
On Tue, Jan 11, 2005 at 09:43:21AM -0500, William Ballard wrote: They ain't there no more. You can't use them. William, you aren't using 'remove' in the same sense Scott and Cameron were. Remember this started when Cameron posited a sequence of operations that dpkg might be going through. Scott posted a correction to that sequence (that there is no 'remove' operation going on). Then you jumped in and said, it looks to me like the old files are clobbered - which happened because you forgot that the topic was about whether dpkg explicitly removed oldpackage before installing newpackage. Yes, you're right, the old files are no longer accessible, but Scott is entitled to be precise when saying that the files are not removed (as canvassed by Cameron), but overwritten. Please accept gracefully that you're both right and move on. If either Scott or Cameron feels my summary is incorrect, please correct me. Vince -- Vincent Ho loki /at/ internode.on.net Every complex problem is a simple hierarchy of simple problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Wed, Jan 12, 2005 at 04:23:19PM +1100, Vincent Ho wrote: entitled to be precise when saying that the files are not removed (as canvassed by Cameron), but overwritten. Please accept gracefully that And *I'm* being precise when I said foo 1.0 is removed and not replaced. A package is not its consituent files. It represents the potential for running it. That is removed and not replaced (until you fix it). Dpkg does not fix it. Thus it removes it. His definition of replace is vacuous. You can't run the program, so fat lot of good the files being replaced does. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: If *-module depends on *-utils, should *-source recommend it?
On Tue, Jan 11, 2005 at 09:57:23PM -0800, Michael K. Edwards wrote: I think I'm of the it's a low-level tool, you can shoot yourself in the foot if you insist on it school. Then the problem is source packages force you to use this low level too. That's why I said I will never install a package with dpkg, but only with apt. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
