RE: Lying to dpkg?
Lying to dpkg eventually causes huge problems and usually a re-install. If you can not install the software from debs, please mail the maintainer or submit bugs. It is very important to debian that all of our software work out of the box for our users. You should never have to see source if you do not want to. So, you have to compile something. Consider using apt-get source and compiling the package yourself, seeing how it works. You may even discover ways to make our system better. OpenSSL is available on the non-us mirrors. add: deb http://non-us.debian.org/debian-non-US/ unstable non-US/main non-US/contrib non-US/non-free to your /etc/apt/sources.list. Two additional pieces of information: mailing package name@packages.debian.org always goes to the maintainer of the package. So mailing say [EMAIL PROTECTED] gets you to the person who can help. install reportbug and use it for bug reporting. It lists open bugs, will give you the bug's info, allow you to submit bugs or add info to existing ones, and more. I hope this helps.
RE: Lying to dpkg?
Lying to dpkg eventually causes huge problems and usually a re-install. Uh-oh! :) Well, I'll probably do a clean install when potato is released as stable anyway. I still don't have an awful lot riding on the current installation. Maybe I'll even try installing apache/php/mysql/mod_ssl/openssl from debs again. If you can not install the software from debs, please mail the maintainer or submit bugs. In my case (never have looked at a unix-like system before) it's more likely that I did something wrong than that there's a problem in the packages. I probably failed to install some package or other that would have acted as a bridge between the various main packages... or something like that. That's my guess anyhow. The problem's more likely with my ignorance than with the debs. At any rate, I don't know how to tell the difference yet. ;) So, you have to compile something. Consider using apt-get source and compiling the package yourself, seeing how it works. I've tried that on a few things now that I (blush) know how it works. That's gone really well, and beats the heck out of trying to figure out how to lie to the system after the fact. Thank you for the help. I will definitely do my best to report bugs as soon as I feel confident enough that what I'm reporting is actually a bug in the software and not in the wetware. Phoenix
Re: Lying to dpkg?
[EMAIL PROTECTED] (Jonas Steverud) wrote: [EMAIL PROTECTED] (Colin Watson) writes: [EMAIL PROTECTED] (Jonas Steverud) wrote: [...] The only problem with this is dselect will tell you the packages made by equivs are obsolete - but I maybe did some wrong when I deleted the .debs? Anyone who knows? Obsolete/local, strictly: it's the local bit that's relevant to you. You can safely ignore this, but if you recreate the .debs and run 'dpkg -A package.deb' then I believe they'll be recorded in the available file and therefore not listed as local. But it will still list the package as obsolete, right? not listed as obsolete/local, I should have said. But ... I mean, the ftpserver will not list it as available and if I'm not misstaken dselect then thinks it's obsolete. The issue isn't that very great, it's just a minor source for irritation - and only sometimes - and I was mostly curious wheather there was something I've overlooked. Ah ... indeed, you're right; now that I've tried it, it works right up to an update. In that case you might want to investigate setting up your own private repository of packages using dpkg-scanpackages; it's not too difficult to do with a bit of trial and error. I'm happy to help you with this if you have problems. -- Colin Watson [EMAIL PROTECTED]
Re: Lying to dpkg?
Phoenix Amon [EMAIL PROTECTED] writes: Is there anyway I can lie to dpkg to convince it that I really do have these packages installed? Or would that not work anyway because programs would look for it in the wrong location? (/usr/bin rather than usr/local/bin or whatever) Have a look at the equivs package. The other programs should find your programs as long as you have them in the $PATH. In the worse case you might have to provide symlinks to the right place (but if $PATH is correctly set that won't be necessary). Download the Contents-i385.gz file for a list of all files and which package they belong to (so you know where to point your symlinks). (man ln for symlinks.) -- ( GnuPG/PGP key @ www.dtek.chalmers.se/~d4jonas/ ! Wei Wu Wei ) ( Meaning of U2 Lyrics, Roleplaying, Emacs/Gnus ! To Do Without Do ) -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: Lying to dpkg?
Jonas wrote: Have a look at the equivs package. The other programs should find your programs as long as you have them in the $PATH. For anyone who's interested, I took this route since it would solve the problem once and for all. Other than the fact that the equivs package fails to list its own dependencies (makedeb was the one that caught me up for a few minutes) it went smoothly and seems to be working perfectly. dpkg and dselect are no longer nagging me about installing apache or mysql. Thanks everyone for the help. Phoenix
Re: Lying to dpkg?
[EMAIL PROTECTED] (Jonas Steverud) wrote: Phoenix Amon [EMAIL PROTECTED] writes: Jonas wrote: Have a look at the equivs package. The other programs should find your programs as long as you have them in the $PATH. For anyone who's interested, I took this route since it would solve the problem once and for all. The only problem with this is dselect will tell you the packages made by equivs are obsolete - but I maybe did some wrong when I deleted the .debs? Anyone who knows? Obsolete/local, strictly: it's the local bit that's relevant to you. You can safely ignore this, but if you recreate the .debs and run 'dpkg -A package.deb' then I believe they'll be recorded in the available file and therefore not listed as local. -- Colin Watson [EMAIL PROTECTED]
Re: Lying to dpkg?
On Wed, 22 Mar 2000, Phoenix Amon wrote: Is there anyway I can lie to dpkg to convince it that I really do have these packages installed? Two things: 1. Use the --ignore-depends flag. 2. RTFM; it's right there. man dpkg (if you've installed man-db). Forgive my ignorance... I'd never seen Linux until about a week ago... and right now I must say that package management has a real heavy-handed big-brotherish feeling to me. Seems like Debian is controlling what I install under Linux more than MS ever controlled what I installed under Win. Debian is good at alleviating the pain of dependencies. Having started working with Linux on early Slackware, I know the horror of manually configuring everything. Moreover, comparing Debian's package management system to MS's won't work, because they don't do nearly the same thing. Most importaqntly, you're under no obligation to use dpkg, as you've clearly already demonstrated to yourself. It is ultimately just Linux, after all. -- Hecubus
Re: Lying to dpkg?
1. Use the --ignore-depends flag. 2. RTFM; it's right there. man dpkg (if you've installed man-db). Thanks and I did. I always do. :) Sometimes TFM doesn't give quite enough info if you don't already know what you're looking for. In a lot of cases TFM serves you well if you know what you're doing and need to jog your memory, but not so well as a learning tool. Debian is good at alleviating the pain of dependencies. That is definitely true. It's very helpful. And I'm not suggesting a direct comparison, because MS doesn't really even have a parallel to dpkg. All I'm saying is that to a newbie, package management as it's currently implemented tends to feel restrictive. It would seem that those more knowledgable often agree, as the debates about whether to make updates to stable fly fast and free. Like you said, I could just avoid using it entirely... but I like it. It's a big time saver. I'd just like to see it get a bit more flexible. Finding ways to work around the system seems to be the topic of a lot of posts around here, and it shouldn't have to be. Phoenix
Re: Lying to dpkg?
[EMAIL PROTECTED] (Phoenix Amon) wrote: Like you said, I could just avoid using it entirely... but I like it. It's a big time saver. I'd just like to see it get a bit more flexible. Finding ways to work around the system seems to be the topic of a lot of posts around here, and it shouldn't have to be. I'd go with one of the ways you suggested in passing in your earlier post; use Debianized source. If you install dpkg-dev and devscripts, it's almost trivial (once you know how) to build a package from source; just do the following: * apt-get source package-name; * change directory into the top-level source directory that will have been created; * modify whatever you want (noting that debian/rules is the main makefile, which calls ./configure and make, so quite often you just need to tweak that a little); * debuild -m'your name your e-mail address' (still in the top-level source directory). This will spit out a .deb in the parent directory of the top-level source directory, which you can then proceed to install with 'dpkg -i'. (You might need to set up gpg first; if you don't it'll probably just complain a little about not finding it but the .deb should still be OK.) Almost any time I need to build something from source I do it this way. You get the bonus that not only does everything go into the standard Debian locations but also all your dependencies get sorted out cleanly. Of course, if it's something that was never a Debian package to start with then you can just build it from upstream source as usual and drop it into /usr/local, and because nothing will depend on it it shouldn't cause any problems. It takes a while to find your way around, but the system *is* actually flexible enough that working within it is sometimes a lot easier than trying to work around it. -- Colin Watson [EMAIL PROTECTED]
Re: Lying to dpkg?
On Wed, 22 Mar 2000, Phoenix Amon wrote: 2. RTFM; it's right there. man dpkg (if you've installed man-db). Sometimes TFM doesn't give quite enough info if you don't already know what you're looking for. In a lot of cases TFM serves you well if you know what you're doing and need to jog your memory, but not so well as a learning tool. I learned how to use dpkg from reading the man page. The thing is, you did know that for which you were looking, else I wouldn't have been able to find the answer. Before you asked, I didn't know how to do it (because I never wanted to). All I'm saying is that to a newbie, package management as it's currently implemented tends to feel restrictive. It would seem that those more knowledgable often agree, as the debates about whether to make updates to stable fly fast and free. I think it's just restrictive enough. At the basic level, it prevents newbies from doing harm to their own systems. However, there exist directives which will allow you to do whatever you want with it, moving from being restricted to being given a warning that you could seriously screw yourself. Given the proper syntax, dpkg allows you to do things it would not advise, basically reverting to, I wouldn't do that if I were you, but it's your computer. You're on your own, pal. Like you said, I could just avoid using it entirely... but I like it. It's a big time saver. I'd just like to see it get a bit more flexible. Finding ways to work around the system seems to be the topic of a lot of posts around here, and it shouldn't have to be. Lots of easy questions are posted to lists like this because people don't bother to read the most obvious documentation. That doesn't mean that the system needs to be changed. Dpkg is flexible, but you need to know how to use it; the information you need is already on your system. UNIX is user-friendly. It's just really selective about who it befriends. -- Hecubus
Re: Lying to dpkg?
I learned how to use dpkg from reading the man page. The thing is, you did know that for which you were looking, else I wouldn't have been able to find the answer. Before you asked, I didn't know how to do it (because I never wanted to). Well, I'll gladly agree to disagree. The last thing I want to do is argue about it. I read the manuals, I read the books I bought, I search the mailing list archives, I read the HOWTOs and FAQs and if all else fails, I ask. Perhaps it is a perfect system and only I am flawed, in which case there need no longer be upgrades to anything but my simple brain. ;) As the variety of responses to my question suggest, there's often more than one way to skin a cat. :) Sometimes the method that makes total sense to one just doesn't click with another. Phoenix
Re: Lying to dpkg?
On Wed, 22 Mar 2000, Phoenix Amon wrote: As the variety of responses to my question suggest, there's often more than one way to skin a cat. :) Ahh... but the different responses addressed the different options you posted. I answered to the specific question of how to make dpkg behave a certain way. There's more than one way to skin a cat, but only half of them are fun. -- Hecubus
Re: Lying to dpkg?
I'd go with one of the ways you suggested in passing in your earlier post; use Debianized source. If you install dpkg-dev and devscripts, it's almost trivial (once you know how) to build a package from source; just do the following: Colin, Thanks for the tip. I unfortunately didn't discover the Debianized source files (oops!) until after my Apache escapade and once I did discover them I didn't understand exactly what they were. I'll definitely file this for later use. Phoenix
