apt-deb: [was Re: Always run dpkg --dry-run -i before running dpkg -i!]
a long time ago, in a thread far, far away... Michelle Konzack wrote: What about dpkg-scanpackages . /dev/null Packages in the same directory and entering the informations in /etc/apt/sources.lists ? After an apt-get update you can use apt-get install to get your package running William Ballard wrote: That's a good idea. Thanks! I wrote a shell script to do this called apt-deb. It turned out a bit complex / ugly in the end! It appears to work ok. You can get it at http://nipl.net/hacks/apt-deb Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
William Ballard [EMAIL PROTECTED] writes: On Fri, Jan 07, 2005 at 12:30:10AM +0100, Jose Carlos Garcia Sogo wrote: including insulting you when you type stupid commands. But you don't have the right to insult people because you are pissed for not being clever enough of looking for dependencies before installing a package by hand using dpkg, which is a low level aimed for admins util, and for not keeping a backup of old package. There is no way to use -source packages without using dpkg. Of cause there is, about a million of them. Check out man dpkg-scanpackages man apt-ftparchive dak on cvs.debian.org mirrorer project on alioth apt-cache show mini-dinstall debpool from experimental the debian-amd64 archive tools sourcerer-kernel-builder for some starting points. The way to go is not to use dpkg -i blindly but to put your build debs somwhere so you can use a proper frontent like apt-get or aptitude. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
Andres Salomon [EMAIL PROTECTED] writes: On Thu, 06 Jan 2005 23:15:53 +0100, Christoph Hellwig wrote: On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Btw, could anyone explain why ndiswrapper is in main? It's only use is to run propritary windows drivers inside the linux kernel, so it's a clear fit for contrib. I believe we had this discussion on IRC; basically, there *are* free (as in speech) ndis drivers out there. Whether they're able to be built and packaged on a debian system; I don't know. Didn't we also say on irc that as long as no free ndis driver is in main it is the same as having no free driver? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
* William Ballard | On Mon, Jan 10, 2005 at 08:33:02PM +0100, Tollef Fog Heen wrote: | dpkg -I on the resulting package and looking at the depends? | | But you don't expect to do that for other packages. If you use dpkg -i, sure you do. dpkg is a low-level tool; treating it as anything else will give surprising and annoying results. | I have started to use temporary apt repositories instead of | dpkg -I which fixes my problem. And accepted that package- | generating packages do not Suggest dependencies of the generated | package. Ok, good. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
[William Ballard] I like my transactions to have ACID consistency and dpkg does not have this by design - apt does. You keep using that word. I do no think it means what you think it means. Let's see how ACID-compliant apt install runs are Atomicity - no. Your install does not, for example, get rolled back if a random postinst script fails. Not even that package gets rolled back. Consistency - this seems to be what you were talking about. Isolation - nope. If you upgrade, say, svn and libsvn0 together, there's a window where users can find themselves using the new svn with the old libsvn0, or vice versa. Durability - I have no idea if dpkg or apt run 'sync' or 'fsync' at useful points (like at the end of the install). Kind of a moot point, though, when you don't have atomicity. So, you're about 1/4 right. Or, being charitable, if you really meant *only* the Consistency part of ACID when you said ACID consistency, then you were right but quite misleading. Peter signature.asc Description: Digital signature
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Sat, Jan 08, 2005 at 01:20:02AM -0600, Peter Samuelson wrote: So, you're about 1/4 right. Or, being charitable, if you really meant *only* the Consistency part of ACID when you said ACID consistency, then you were right but quite misleading. I know what it means, you're being pedagogical. For the purposes of this discussion, it fits. The domain of discourse is dependencies. Assuming no packages are broken (i.e., our Transaction Monitor works...) Atomic: All of the dependencies are installed or none of them are. Consistent: The system is transformed from one correct state to another correct state. Isolated: Other installations will not be broken by this installation. Durable: Dpkg is already durable. You probably aren't aware of my extensions of how I work with apt repositories which allows me to commit or roll back transactions. If an apt-operation succeed I move the files to a new known good repository. If it fails I perform a balancing apt operation on using the old state. Actually apt is like a Serializable transaction: All locks are acquired before any locks are released, in the sense that it's guaranteed to succeed if it starts, assuming individual packages themselves aren't broken. Plus you're just being pedantic. It's not exactly like a database it's just a metaphor. Whatever it is is what it is.
Re: Always run dpkg --dry-run -i before running dpkg -i!
#include hallo.h * Greg Folkert [Thu, Jan 06 2005, 07:13:02PM]: The temporary apt-repository is the only reliable solution. m-a is solving a problem I don't have. Fine then, don't use it. It'll pull the deps before it install the modules and unloads them and re-loads them. No, it doesn't. It uses the same cludge that most people would run by hand (blind dpkg -i, on failure apt-get -f install). In fact, I did nit find a clear solution to extract the list of dependencies and feed apt with them when I wrote that part of code. Regards, Eduard.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, 6 Jan 2005 17:29:27 -0500, William Ballard wrote: On Thu, Jan 06, 2005 at 11:22:47PM +0100, Joerg Jaspert wrote: Sorry, but a package can't install a brain. It builds a new package, so you look at that one before you do anything. Where is the problem? Why even bother having the concept of dependencies in the first place? Why not just look at what anything needs and make sure it's always there first? I don't know what dpkg bothers to try to install things it should be able to know beforehand won't succeed. The problem is it uninstalls the old version of the thing, so now whatever functionality you had is gone. Could you possibly explain clearly what is the difference between using dpkg -i to install a package build from some *-source and using it to install _any_ _other_ _package_? If you want the convenience of automatic dependencies installation use a frontend, you have been told how to. Otherwise dependencies are there for dpkg to know that it cannot configure a package, and for you to look at them. The way dpkg works is known since well in the last century and, be it a good way or not (eg. rpm does it your way), any administrator using dpkg without considering it deserves what they get. -- Micha Politowski Talking has been known to lead to communication if practised carelessly. signature.asc Description: Digital signature
Re: Always run dpkg --dry-run -i before running dpkg -i!
[Please don't mail -qa with ill-formed rants. They are not appropriate there. They are also not appropriate in the bug tracking system, so I've removed the off-topic #287949 from the cc list.] On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: Given that -source packages do not adequately specify the dependencies to be able to use the output, one must NEVER run dpkg -i a given deb without first running dpkg --dry-run -i on the same debs and verifying that it returns a zero exit code. Are you aware that dpkg --dry-run -i unpacks the new package before checking that the package can be configured (i.e. it's equivalent to dpkg --dry-run --unpack; dpkg --dry-run --configure), so your solution is at best a no-op? See bug #183470. In fact, your approach is worse because --no-act doesn't even report dependency problems encountered in the configure step, nor exit non-zero when it encounters them. See bug #55364. It's much more efficient for users to keep the old .debs around and simply use dpkg -i, which will exit non-zero on errors and allow you to put the old .deb back. Seems clear that you didn't try this before recommending it ... Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Fri, Jan 07, 2005 at 11:22:43AM +, Colin Watson wrote: On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: Given that -source packages do not adequately specify the dependencies to be able to use the output, one must NEVER run dpkg -i a given deb without first running dpkg --dry-run -i on the same debs and verifying that it returns a zero exit code. Are you aware that dpkg --dry-run -i unpacks the new package before checking that the package can be configured (i.e. it's equivalent to dpkg --dry-run --unpack; dpkg --dry-run --configure), so your solution is at best a no-op? See bug #183470. In fact, your approach is worse because --no-act doesn't even report dependency problems encountered in the configure step, nor exit non-zero when it encounters them. See bug #55364. It's much more efficient for users to keep the old .debs around and simply use dpkg -i, which will exit non-zero on errors and allow you to put the old .deb back. Seems clear that you didn't try this before recommending it ... Actually, I take some of that back; dpkg --no-act -i apparently does check dependencies well enough now. However, it doesn't report errors usefully either in its output or in its exit code, so it's only useful if you're familiar with it and are paying a lot of attention: $ sudo dpkg --no-act -i kdepim_3.3.1-3_all.deb Selecting previously deselected package kdepim. (Reading database ... 119331 files and directories currently installed.) Unpacking kdepim (from kdepim_3.3.1-3_all.deb) ... $ echo $? 0 $ dpkg -l kdepim Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- pn kdepim none (no description available) $ dpkg -L kdepim Package `kdepim' is not installed. Use dpkg --info (= dpkg-deb --info) to examine archive files, and dpkg --contents (= dpkg-deb --contents) to list their contents. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Fri, Jan 07, 2005 at 11:08:40AM +0100, Michal Politowski wrote: Could you possibly explain clearly what is the difference between using dpkg -i to install a package build from some *-source and using it to install _any_ _other_ _package_? If you want the convenience of automatic dependencies installation use a frontend, you have been told how to. None of the frontends (TTBOMK) allow you to install an arbitrary .deb file though; they all want to fetch from a package repository. apt-get install file.deb has been proposed before but isn't implemented. Yet it's what's needed here (or equivalent). As a workaround, the generated modules package could pre-depend on the utils package. That would stop dpkg from unpacking it and leaving a useless installation. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
Scripsit Hamish Moffatt [EMAIL PROTECTED] As a workaround, the generated modules package could pre-depend on the utils package. That would stop dpkg from unpacking it and leaving a useless installation. Is the installation really more useless with the modules unpackaged-but-not-configured than with the modules not unpacked at all? I fail to imagine any situation where that could be the case. -- Henning MakholmUnmetered water, dear. Run it deep.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Fri, Jan 07, 2005 at 02:55:55PM +, Henning Makholm wrote: Scripsit Hamish Moffatt [EMAIL PROTECTED] As a workaround, the generated modules package could pre-depend on the utils package. That would stop dpkg from unpacking it and leaving a useless installation. Is the installation really more useless with the modules unpackaged-but-not-configured than with the modules not unpacked at all? I fail to imagine any situation where that could be the case. I don't know. That was the impression I got from the OP's rantings. It seemed that the old package worked without the -utils, but the new package didn't. So when the new package was unpacked (but couldn't be configured), it broke the working installation. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Sat, Jan 08, 2005 at 12:29:20PM +1100, Hamish Moffatt wrote: I don't know. That was the impression I got from the OP's rantings. It seemed that the old package worked without the -utils, but the new package didn't. So when the new package was unpacked (but couldn't be configured), it broke the working installation. Right. Although technically the kernel module would still be loaded so the network would still work until you reboot. To be slap honest I actually didn't have too much problems -- I had manually copied backup debs over before the upgrade, but I resented the fact that the *-source package built a deb that required so much TLC and planning to work with. I would have hoped the *-source package would wear it's requirement on it's sleeve. The takeaway I've gotten from this is dpkg is dumb as a brick and I will only *ever* use apt from a temporary repository. I like my transactions to have ACID consistency and dpkg does not have this by design - apt does.
Always run dpkg --dry-run -i before running dpkg -i!
Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Since his package (and theoretically any package which generates packages) may be uninstallable because there is no way to say give me the source and everything I need to be able to use the output via Recommends, or a foo-source-end-user metapackage which depends on foo-source and foo-utils, we are left in the situation of not being able to trust that -source packages won't hork our system. (If the package is a network card driver source package our system may then be unfixable because now our network card is hosed). Given that -source packages do not adequately specify the dependencies to be able to use the output, one must NEVER run dpkg -i a given deb without first running dpkg --dry-run -i on the same debs and verifying that it returns a zero exit code. I don't know why this isn't the default behavior of dpkg -i, checking that at least all dependencies will be met before uninstalling old packages and leaving the system broken.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, 6 Jan 2005, William Ballard wrote: Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Since his package (and theoretically any package which generates packages) may be uninstallable because there is no way to say give me the source and everything I need to be able to use the output via Recommends, or a foo-source-end-user metapackage which depends on foo-source and foo-utils, we are left in the situation of not being able to trust that -source packages won't hork our system. (If the package is a network card driver source package our system may then be unfixable because now our network card is hosed). Given that -source packages do not adequately specify the dependencies to be able to use the output, one must NEVER run dpkg -i a given deb without first running dpkg --dry-run -i on the same debs and verifying that it returns a zero exit code. I don't know why this isn't the default behavior of dpkg -i, checking that at least all dependencies will be met before uninstalling old packages and leaving the system broken. Er, huh? I don't see what problem you are describing. What *exactly* is the issue you have?
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Eh, if you start a mail like this, I don't even read further on this mail... sorry. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, 6 Jan 2005, Adam Heath wrote: On Thu, 6 Jan 2005, William Ballard wrote: Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Since his package (and theoretically any package which generates packages) may be uninstallable because there is no way to say give me the source and everything I need to be able to use the output via Recommends, or a foo-source-end-user metapackage which depends on foo-source and foo-utils, we are left in the situation of not being able to trust that -source packages won't hork our system. (If the package is a network card driver source package our system may then be unfixable because now our network card is hosed). Given that -source packages do not adequately specify the dependencies to be able to use the output, one must NEVER run dpkg -i a given deb without first running dpkg --dry-run -i on the same debs and verifying that it returns a zero exit code. I don't know why this isn't the default behavior of dpkg -i, checking that at least all dependencies will be met before uninstalling old packages and leaving the system broken. Er, huh? I don't see what problem you are describing. What *exactly* is the issue you have? I've now taken time to read the bug report. You're wrong, and the maintainer is right.
Re: Always run dpkg --dry-run -i before running dpkg -i!
Am 2005-01-06 16:58:56, schrieb William Ballard: Given that -source packages do not adequately specify the dependencies to be able to use the output, one must NEVER run dpkg -i a given deb without first running dpkg --dry-run -i on the same debs and verifying that it returns a zero exit code. What about dpkg-scanpackages . /dev/null Packages in the same directory and entering the informations in /etc/apt/sources.lists ? After an apt-get update you can use apt-get install to get your package running Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Always run dpkg --dry-run -i before running dpkg -i!
Am 2005-01-06 23:02:40, schrieb Jeroen van Wolffelaar: On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Eh, if you start a mail like this, I don't even read further on this mail... sorry. :-) --Jeroen Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 11:02:40PM +0100, Jeroen van Wolffelaar wrote: On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Eh, if you start a mail like this, I don't even read further on this mail... sorry. Yeah, the other guy decided to be a dick too, so you've got company.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 04:05:24PM -0600, Adam Heath wrote: I've now taken time to read the bug report. You're wrong, and the maintainer is right. Well that's why you simply cannot trust that source packages will not completely fuck up your system.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 04:02:17PM -0600, Adam Heath wrote: On Thu, 6 Jan 2005, William Ballard wrote: Er, huh? I don't see what problem you are describing. What *exactly* is the issue you have? Packages that generate packages as output that have dependencies the original package does not have. The resulting output may be uninstallable. The rationale is some people just want to build them. But the package doesn't give me any clue that I'm about to shoot myself in the foot.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Btw, could anyone explain why ndiswrapper is in main? It's only use is to run propritary windows drivers inside the linux kernel, so it's a clear fit for contrib.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, 6 Jan 2005, William Ballard wrote: On Thu, Jan 06, 2005 at 11:02:40PM +0100, Jeroen van Wolffelaar wrote: On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Eh, if you start a mail like this, I don't even read further on this mail... sorry. Yeah, the other guy decided to be a dick too, so you've got company. The only person here I see acting inappropriately(name calling, etc) is you. You may not agree with the maintainer's responses, but that doesn't mean he's a dick(head). Again, reading the report, I see you getting more and more frustrated, and then resorting to name calling, and dirt throwing(publically, on this list). Both are signs of poor ettiquette.
Re: Always run dpkg --dry-run -i before running dpkg -i!
* William Ballard wrote: [...crap...] Do you need the -utils apckage to build the -source package? No. So no Depends and no Recommends for you. Period. Depends and Recommends have a certain well-defined meaning and I am greatful that we are not arbitarily misusing them. The resulting -modules package has a depends on the -utils package, which is everything that is needed. Sebastian -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 11:10:16PM +0100, Michelle Konzack wrote: Am 2005-01-06 16:58:56, schrieb William Ballard: Given that -source packages do not adequately specify the dependencies to be able to use the output, one must NEVER run dpkg -i a given deb without first running dpkg --dry-run -i on the same debs and verifying that it returns a zero exit code. What about dpkg-scanpackages . /dev/null Packages in the same directory and entering the informations in /etc/apt/sources.lists ? After an apt-get update you can use apt-get install to get your package running That's a good idea. Thanks!
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, 6 Jan 2005, Sebastian Ley wrote: * William Ballard wrote: [...crap...] Do you need the -utils apckage to build the -source package? No. So no Depends and no Recommends for you. Period. Depends and Recommends have a certain well-defined meaning and I am greatful that we are not arbitarily misusing them. The resulting -modules package has a depends on the -utils package, which is everything that is needed. It *may* require a versioned depends on a newer version, but that's just a normal bug.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 04:18:36PM -0600, Adam Heath wrote: Again, reading the report, I see you getting more and more frustrated, and then resorting to name calling, and dirt throwing(publically, on this list). Both are signs of poor ettiquette. I offered the asshole and alternative and he said make up your mind
Re: Always run dpkg --dry-run -i before running dpkg -i!
On 10161 March 1977, William Ballard wrote: Er, huh? I don't see what problem you are describing. What *exactly* is the issue you have? Packages that generate packages as output that have dependencies the original package does not have. The resulting output may be uninstallable. The rationale is some people just want to build them. But the package doesn't give me any clue that I'm about to shoot myself in the foot. Sorry, but a package can't install a brain. It builds a new package, so you look at that one before you do anything. Where is the problem? -- bye Joerg 2.5 million B.C.: OOG the Open Source Caveman develops the axe and releases it under the GPL. The axe quickly gains popularity as a means of crushing moderators heads.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 11:19:35PM +0100, Sebastian Ley wrote: * William Ballard wrote: [...crap...] Do you need the -utils apckage to build the -source package? No. So no Depends and no Recommends for you. Period. Depends and Recommends have a certain Well you can't use the damn thing without other stuff, and it never says you need this stuff to use it. Tell my why you'd ever want ndiswrapper-utils and not ndiswrapper-source. Then tell me if that's the most common case. There should be *some* way to say I want to be able to use this thing instead of just giving it to somebody else. Just tell me how you work around this problem and I'm having, and I'll shut up. That's what I told the maintainer and he never responded. Just tell me how I'm supposed to just know to get -utils? Wait until it breaks?
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 04:18:36PM -0600, Adam Heath wrote: Again, reading the report, I see you getting more and more frustrated, and then resorting to name calling, and dirt throwing(publically, on this list). Both are signs of poor ettiquette. I offered the asshole and alternative and he said make up your mind
Re: Always run dpkg --dry-run -i before running dpkg -i!
* Adam Heath wrote: It *may* require a versioned depends on a newer version, but that's just a normal bug. ...and no reason to introduce this dependency in the -source package. Btw: Leaving old packages build from -source packages around would quite well do the trick. But I suppose W.B. wants to call more people assholes before invoking brain functions... *sigh* Sebastian -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 11:22:47PM +0100, Joerg Jaspert wrote: Sorry, but a package can't install a brain. It builds a new package, so you look at that one before you do anything. Where is the problem? Why even bother having the concept of dependencies in the first place? Why not just look at what anything needs and make sure it's always there first? I don't know what dpkg bothers to try to install things it should be able to know beforehand won't succeed. The problem is it uninstalls the old version of the thing, so now whatever functionality you had is gone.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 11:28:55PM +0100, Sebastian Ley wrote: Btw: Leaving old packages build from -source packages around would quite well do the trick. But I suppose W.B. wants to call more people assholes before invoking brain functions... Right: I have to do all this special stuff to fix things that break because for god's sake the source package isn't going to help me out. For some strange reason with source packages Debian has decided aw the RPM model's not so bad. Just don't fuck up!
Re: Always run dpkg --dry-run -i before running dpkg -i!
William Ballard [EMAIL PROTECTED] writes:
Given that -source packages do not adequately specify the dependencies
to be able to use the output, one must NEVER run dpkg -i a given deb
without first running dpkg --dry-run -i on the same debs and verifying
that it returns a zero exit code.
Like rm, dpkg is a tool for system administrators. It will not protect
you from potentially harmful actions because it assumes that you know
what you do.
Marc
--
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,u(kcapnu ,nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa{gwmclBHIbus}gwmclBHI{yVGa09mbbus}yVGa09mb{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse # mailto:[EMAIL PROTECTED]
pgpkRL9fEOpti.pgp
Description: PGP signature
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 11:37:52PM +0100, Marc 'HE' Brockschmidt wrote: William Ballard [EMAIL PROTECTED] writes: Given that -source packages do not adequately specify the dependencies to be able to use the output, one must NEVER run dpkg -i a given deb without first running dpkg --dry-run -i on the same debs and verifying that it returns a zero exit code. Like rm, dpkg is a tool for system administrators. It will not protect you from potentially harmful actions because it assumes that you know what you do. I already knew that. That's why I said you have to use it in this special way. Or else maybe you just like eyeballing things and doing everything manually, and you run slackware.
Re: Always run dpkg --dry-run -i before running dpkg -i!
#include hallo.h * William Ballard [Thu, Jan 06 2005, 05:14:32PM]: What *exactly* is the issue you have? Packages that generate packages as output that have dependencies the original package does not have. The resulting output may be uninstallable. Though luck. The rationale is some people just want to build them. From my point of view, those source packages are most often installed by a dependency of some other *utilities* package. Once they are installed, $user can use module-assistant or make-kpkg to generate and install the modules. AFAICS you fail to realize that the way you like it is not always the best way or the way that should be liked by everyone. But the package doesn't give me any clue that I'm about to shoot myself in the foot. The dependencies may be mentioned in the Suggests of the souce package, but not more, because otherwise you would have circular dependencies (or non-sense dependencies), no good choice at all. Regards, Eduard. -- schneckal hat einer von euch schon bind9 installiert? eis das neue root kit? :-
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 11:27:59PM +0100, Eduard Bloch wrote: From my point of view, those source packages are most often installed by a dependency of some other *utilities* package. Once they are installed, So, what you're saying is, if I need some module foo source, I should look to be installing foo-utils and expect foo-source to tag along. If I don't find foo-utils, just look for foo-source. Can I count on foo-utils Suggesting foo-source? Is there a policy I can read?
Re: Always run dpkg --dry-run -i before running dpkg -i!
#include hallo.h * William Ballard [Thu, Jan 06 2005, 05:50:46PM]: So, what you're saying is, if I need some module foo source, I should look to be installing foo-utils and expect foo-source to tag along. If I don't find foo-utils, just look for foo-source. Can I count on foo-utils Suggesting foo-source? Is there a policy I can read? AFAICS there is no complete policy for 3rd party module/source packages(*). There are some packaging hints in the make-kpkg docs and I added a guide to module-assistant documentation. (*) I have tried to write one, but that has been a long time ago, IIRC when Herbert was still around. No idea where the paper now is, most likely between the unchecked stuff from old gluck... Regards, Eduard.
Re: Always run dpkg --dry-run -i before running dpkg -i!
El jue, 06-01-2005 a las 17:21 -0500, William Ballard escribi: On Thu, Jan 06, 2005 at 04:18:36PM -0600, Adam Heath wrote: Again, reading the report, I see you getting more and more frustrated, and then resorting to name calling, and dirt throwing(publically, on this list). Both are signs of poor ettiquette. I offered the asshole and alternative and he said make up your mind Could you please stop insulting people who is pending time to help you? If you want, you can write your own dpkg making the things you want, including insulting you when you type stupid commands. But you don't have the right to insult people because you are pissed for not being clever enough of looking for dependencies before installing a package by hand using dpkg, which is a low level aimed for admins util, and for not keeping a backup of old package. So please, stop trolling. Thanks, -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Always run dpkg --dry-run -i before running dpkg -i!
El jue, 06-01-2005 a las 17:50 -0500, William Ballard escribi: On Thu, Jan 06, 2005 at 11:27:59PM +0100, Eduard Bloch wrote: From my point of view, those source packages are most often installed by a dependency of some other *utilities* package. Once they are installed, So, what you're saying is, if I need some module foo source, I should look to be installing foo-utils and expect foo-source to tag along. If I don't find foo-utils, just look for foo-source. No, you should use module-assistant tool, which is a high level tool that tries to avoid those problems. When you use a low level tool, you have to know how to use it, and which can be the effects of using it in some way or another. Can I count on foo-utils Suggesting foo-source? Is there a policy I can read? Yup, it is called Debian Policy. -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Fri, Jan 07, 2005 at 12:30:10AM +0100, Jose Carlos Garcia Sogo wrote: including insulting you when you type stupid commands. But you don't have the right to insult people because you are pissed for not being clever enough of looking for dependencies before installing a package by hand using dpkg, which is a low level aimed for admins util, and for not keeping a backup of old package. There is no way to use -source packages without using dpkg. Some people here have offered alternatives, and I was just asking for alternatives, and got stoned silence. You for example didn't tell me a thing except lump it. But I get it now: dpkg is no smarter than rpm. Lots of people don't like RPM based distros because they break. I might point out that source packages by design expect you to use dpkg so by conclusion people aren't going to like them any more than they like RPM-based distros. I understand foo-source not Depending on foo-utils. I do not understand foo-source not Suggesting foo-utils, or something like foo-source-installable depending on foo-source and foo-utils.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Fri, Jan 07, 2005 at 12:32:50AM +0100, Jose Carlos Garcia Sogo wrote: No, you should use module-assistant tool, which is a high level tool If I have installed module-assistant and ndiswrapper-source and have not installed ndiswrapper-utils and install ndiswrapper-modules the modules-assistant way, what happens? Does it (a) break during install (b) tell me it won't install correctly or (c) download and install it for me? Yup, it is called Debian Policy. Funny, the author of module-assistant just said there is no policy for 3rd policy modules. He said there's some stuff, but not as categorically full stop as you said it. Funny, huh.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, 06 Jan 2005 23:15:53 +0100, Christoph Hellwig wrote: On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Btw, could anyone explain why ndiswrapper is in main? It's only use is to run propritary windows drivers inside the linux kernel, so it's a clear fit for contrib. I believe we had this discussion on IRC; basically, there *are* free (as in speech) ndis drivers out there. Whether they're able to be built and packaged on a debian system; I don't know.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, 2005-01-06 at 17:30 -0500, William Ballard wrote: On Thu, Jan 06, 2005 at 11:28:55PM +0100, Sebastian Ley wrote: Btw: Leaving old packages build from -source packages around would quite well do the trick. But I suppose W.B. wants to call more people assholes before invoking brain functions... Right: I have to do all this special stuff to fix things that break because for god's sake the source package isn't going to help me out. For some strange reason with source packages Debian has decided aw the RPM model's not so bad. Just don't fuck up! There is a reason for build-dep, it only install the needed things to compile. There is a reason there is a package called: module-assistant I have previous to its introduction, sweat bullets when ever I did the things it does... so much so that I created a shell script to remind me of all the steps. Asking me questions along the way. I nearly always have a second term open to the machine I am working on... to double check many things. Tonight, I nearly screwed the pooch. On one of my production machines, I was doing cleanup like I normally do... well my Lab-Boxer mix 8 month old puppy (not small by any means) decided it want to play. She out her playtoy on my keyboard as I was going to remove /lib/modules/2.4.26/kernel/drivers/net/ipv4/netfilter/ I got to: /lib/modules/2.4.26/kernel/drivers/net/ipv4 when she drop the toy on my numeric-pad enter key. Since this was an RPM machine... I always keep those custom compiled packages around, usually about 3-4 versions. I was able to look at the config, saw that I had compiled in all of ipv4 except the netfilter. So I was cool. Still I could have re-installed the kernel RPM. I also, keep a HUGE repository of Debian packages, my autoclean actually does a copy of all the files it is going to delete to an nfs mount. That way I can always sneaker net the packages over if I gotta. Sorry WB, but the argument you started (by you) was lost when you did not CYA. Why do we have to pay with bearing crudeness for your, albeit accidental, mistake. It is annoying to have this stuff happen, but as with all things, we tend to become complacent with things and drop our standards/guards down a bit. When we get bit, it hurts. We do it over and over and over again. Me, I do stuff blindly, mainly because I know I can recover my mistakes. Doing the self-foot(shoot)... well its not always easy to swallow especially when you have limited resources at the locale you might be at (Like Ma's home, or the CEO's Home Office) -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, 2005-01-06 at 18:46 -0500, William Ballard wrote: On Fri, Jan 07, 2005 at 12:32:50AM +0100, Jose Carlos Garcia Sogo wrote: No, you should use module-assistant tool, which is a high level tool If I have installed module-assistant and ndiswrapper-source and have not installed ndiswrapper-utils and install ndiswrapper-modules the modules-assistant way, what happens? Does it (a) break during install (b) tell me it won't install correctly or (c) download and install it for me? (c) Download and install it for you. Used it many a time to install nvidia stuff, being one of the particular ones I do, do regularly. It grabs all the GL stuff and nvidia utils. Yup, it is called Debian Policy. Funny, the author of module-assistant just said there is no policy for 3rd policy modules. He said there's some stuff, but not as categorically full stop as you said it. Funny, huh. There is no policy for 3rd party. But, use the tools available and help yourself alot. I resisted module-assistant until I used it. Took me 3 times to make sure I was actually seeing what I was seeing. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 06:55:47PM -0500, Greg Folkert wrote: (c) Download and install it for you. You're right, but there's still one problem: It breaks first and *then* fixes it. By the time it's broken, your old network card no longer works and you can't connect to an apt repository to fix it. Doesn't this put network card source packages in a special category? I mentioned this in my bug report. m-a should see if it's going to break before it breaks Now you're going to say: keep around old packages in case it breaks, what are you stupid? it's the kernel! keep backups and I'll say: you knew before-hand it was going to break, why'd you break it? The temporary apt-repository is the only reliable solution. m-a is solving a problem I don't have.
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, 2005-01-06 at 19:09 -0500, William Ballard wrote: On Thu, Jan 06, 2005 at 06:55:47PM -0500, Greg Folkert wrote: (c) Download and install it for you. You're right, but there's still one problem: It breaks first and *then* fixes it. By the time it's broken, your old network card no longer works and you can't connect to an apt repository to fix it. Doesn't this put network card source packages in a special category? I mentioned this in my bug report. m-a should see if it's going to break before it breaks Now you're going to say: keep around old packages in case it breaks, what are you stupid? it's the kernel! keep backups and I'll say: you knew before-hand it was going to break, why'd you break it? The temporary apt-repository is the only reliable solution. m-a is solving a problem I don't have. Fine then, don't use it. It'll pull the deps before it install the modules and unloads them and re-loads them. If you want to keep shooting self in foot please do so quietly. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 07:13:02PM -0500, Greg Folkert wrote: Fine then, don't use it. It'll pull the deps before it install the modules and unloads them and re-loads them. I just didn't realize this crap was so brittle. So many ways to fix brokenness when I just don't know why dpkg even bothers starting it knows it can't finish. Sure you can say it's for experts but half-installing something you know the dependencies aren't there should be a Forced option, not the default. The solutioun as everybody has said and how I started this thread is just don't trust dpkg anymore than you trust rpm. apt-get direct packages or temporary apt repositories for me
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 06:50:59PM -0500, Andres Salomon wrote: On Thu, 06 Jan 2005 23:15:53 +0100, Christoph Hellwig wrote: On Thu, Jan 06, 2005 at 04:58:56PM -0500, William Ballard wrote: Apparently the dickhead maintainer of ndiswrapper-source has just gone into his shell and refuses to discuss this problem. Btw, could anyone explain why ndiswrapper is in main? It's only use is to run propritary windows drivers inside the linux kernel, so it's a clear fit for contrib. I believe we had this discussion on IRC; basically, there *are* free (as in speech) ndis drivers out there. Whether they're able to be built and packaged on a debian system; I don't know. It's completely irrelevant whether any free drivers exist. ndiswrapper's purpose is to provide an NDIS interface to the Linux kernel, and it accomplishes that purpose without the use of any non-free software. Thus, it is perfectly suitable for main. -- For every sprinkle I find, I shall kill you!
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, Jan 06, 2005 at 04:31:14PM -0800, Brian Nelson wrote: It's completely irrelevant whether any free drivers exist. ndiswrapper's purpose is to provide an NDIS interface to the Linux kernel, and it accomplishes that purpose without the use of any non-free software. Thus, it is perfectly suitable for main. We have other software in contrib that depends on software which is currently only available in non-free. Generally we have included that software in contrib until a free equivalent is actually available. (Though current main does include a few counter-examples.) Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
On Thu, 2005-01-06 at 19:25 -0500, William Ballard wrote: On Thu, Jan 06, 2005 at 07:13:02PM -0500, Greg Folkert wrote: Fine then, don't use it. It'll pull the deps before it install the modules and unloads them and re-loads them. I just didn't realize this crap was so brittle. So many ways to fix brokenness when I just don't know why dpkg even bothers starting it knows it can't finish. Sure you can say it's for experts but half-installing something you know the dependencies aren't there should be a Forced option, not the default. The solutioun as everybody has said and how I started this thread is just don't trust dpkg anymore than you trust rpm. apt-get direct packages or temporary apt repositories for me Well, at least we all have learned from your mistake Too bad it happened. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
