Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 08:23:16AM -0500, John Hasler wrote: Thomas Adam writes: As I have said, if the file was created by an application, then it clearly cannot belong to a package. The question was about files created by the maintainer scripts. Was it now? I don't believe so, although files created by maintainer scripts is one aspect to the question. But the answer will still be the same. I'm not sure how many times I have to re-iterate it, but: If a file is created by an application, then the file will not be part of any package, unless the file in question was already part of the package. Just off the top of my head I see no reason why these files could not be included in the package empty and filled in by the scripts. This would identify the files as belonging to the package and also allow dpkg to remove them, eliminating the need for the postrm to do so. The overhead in doing this is stupid, and having a lot of empty files in /etc is just pointless. -- Thomas Adam -- Frankly, Mr. Shankly, since you ask. You are a flatulent pain in the arse. -- Morrissey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 09:24:45AM -0400, Carl Fink wrote: On Tue, Aug 24, 2004 at 01:54:41PM +0100, Thomas Adam wrote: On Tue, Aug 24, 2004 at 08:49:57AM -0400, Jason Rennie wrote: dpkg -S | --search filename-search-pattern ... Search for a filename from installed packages. How is this unclear, exactly? It doesn't say, Search for a filename THAT IS CONTAINED WITHIN an installed package. Why wouldn't the above include programmatically-generated configuration files? They're from the package. They're not from any package -- they're created by programs that are themselves from packages. But how on Earth can you keep information as to programs that created files? It's a stupid and pointless exercise. Please see my other posts as to the explanations why. -- Thomas Adam -- Frankly, Mr. Shankly, since you ask. You are a flatulent pain in the arse. -- Morrissey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Jason Rennie wrote: ... Geez. Try answering the question, not insulting the guy. Don't worry - i'm used to it on this list by now... :-) -- Paul http://paulgear.webhop.net -- Did you know? Email addresses can be forged easily. This message is signed with GNU Privacy Guard http://www.gnupg.org and Enigmail http://enigmail.mozdev.org so you can be sure it comes from me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Thomas Adam wrote: On Tue, Aug 24, 2004 at 09:24:45AM -0400, Carl Fink wrote: On Tue, Aug 24, 2004 at 01:54:41PM +0100, Thomas Adam wrote: On Tue, Aug 24, 2004 at 08:49:57AM -0400, Jason Rennie wrote: dpkg -S | --search filename-search-pattern ... Search for a filename from installed packages. How is this unclear, exactly? It doesn't say, Search for a filename THAT IS CONTAINED WITHIN an installed package. Why wouldn't the above include programmatically-generated configuration files? They're from the package. They're not from any package -- they're created by programs that are themselves from packages. But how on Earth can you keep information as to programs that created files? It's a stupid and pointless exercise. Please see my other posts as to the explanations why. Seems to me the idea of creating configuration files on the fly is broken. I much prefer this: # to list configuration files [EMAIL PROTECTED]:~ rpm -qc glibc-2.3.2-120 /etc/nscd.conf /etc/rpc #to find what owns a configuration file: [EMAIL PROTECTED]:~ rpm -qf /etc/defaultdomain netcfg-9.0-7 [EMAIL PROTECTED]:~ To find what documentation might pertain to the configuration file: [EMAIL PROTECTED]:~ rpm -qdf /etc/defaultdomain [EMAIL PROTECTED]:~ Bad example, there is none in that package. This is better: [EMAIL PROTECTED]:~ rpm -qf /usr/share/man/man8/rpcinfo.8.gz glibc-2.3.2-120 [EMAIL PROTECTED]:~ rpm -qfd /usr/share/man/man8/rpcinfo.8.gz /usr/share/doc/packages/glibc/LICENSES /usr/share/man/man1/getconf.1.gz /usr/share/man/man1/getent.1.gz /usr/share/man/man1/glibcbug.1.gz /usr/share/man/man1/iconv.1.gz /usr/share/man/man1/ldd.1.gz /usr/share/man/man1/locale.1.gz /usr/share/man/man1/localedef.1.gz /usr/share/man/man5/locale.alias.5.gz /usr/share/man/man5/nscd.conf.5.gz /usr/share/man/man8/ldconfig.8.gz /usr/share/man/man8/nscd.8.gz /usr/share/man/man8/nscd_nischeck.8.gz /usr/share/man/man8/rpcinfo.8.gz [EMAIL PROTECTED]:~ The above is on SuSE. In contrast, my Debian system has /etc/defaultdomain but no man page: SuSE's man page is in another package. I would expect every file in /etc on the SuSE (or a Red Hat) system to be owned by a package, unless I created it. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, 24 Aug 2004, Thomas Adam wrote: On Tue, Aug 24, 2004 at 10:28:09PM +1000, Paul Gear wrote: Is it fairly common, then, that packages only create their config files, and don't include them in the package originally. I can see times when Of course it is. There are *hundreds* of files that are created in this manner, usually brought about because they're created by the very programs in other packages, and so there is no way of ever supplying the files in the first place. Or by debconf-ization of packages, which often need this. that would lead to confusion. Is there another way to find out where a file belongs? No, since any answer would be completely erroneous. Actually, we have been requesting this functionality to the dpkg crew for a while. It will arrive someday. The idea is that we will register dynamically-created stuff with a package in the maintainer script. But right now, all you can do if you *really* need to find out where a package came from is to use dpkg -L, and when that fails, try to grep for that filename in /var/lib/dpkg/info, which might or might not help. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, 24 Aug 2004, Thomas Adam wrote: On Tue, Aug 24, 2004 at 08:23:16AM -0500, John Hasler wrote: Just off the top of my head I see no reason why these files could not be included in the package empty and filled in by the scripts. This would identify the files as belonging to the package and also allow dpkg to remove them, eliminating the need for the postrm to do so. The overhead in doing this is stupid, and having a lot of empty files in /etc is just pointless. But we could be doing that if it worked. It doesn't. Hint: empty files, as well as missing files, are valid states of a conffile and dpkg would act accordingly. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler writes: Just off the top of my head I see no reason why these files could not be included in the package empty and filled in by the scripts. This would identify the files as belonging to the package and also allow dpkg to remove them, eliminating the need for the postrm to do so. I think the canonical answer is that some programs will behave differently if a config file exists (even if empty) than if it doesn't exist. E.g., /etc/nologin -- you wouldn't want to ship that :-) Then there are some files that it's questionable who they would belong to. For instance, /etc/ld.so.conf needs to be modified by several packages; if it was owned by some package, it would be a Policy violation for any other package to touch it. Then someone would have to write an update-ld.so.conf script, which just seems like overkill. I agree that the vast majority of postinst-created files in /etc don't meet either of these criteria, so the suggestion makes sense there. My understanding is that there is long-term work planned on dpkg to allow registering a list of related files on package installation, even if they aren't actually in the package. -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG public key ID: 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 11:33:09AM -0300, Henrique de Moraes Holschuh wrote: On Tue, 24 Aug 2004, Thomas Adam wrote: On Tue, Aug 24, 2004 at 10:28:09PM +1000, Paul Gear wrote: Is it fairly common, then, that packages only create their config files, and don't include them in the package originally. I can see times when Of course it is. There are *hundreds* of files that are created in this manner, usually brought about because they're created by the very programs in other packages, and so there is no way of ever supplying the files in the first place. Or by debconf-ization of packages, which often need this. Yes, I mentioned that. that would lead to confusion. Is there another way to find out where a file belongs? No, since any answer would be completely erroneous. Actually, we have been requesting this functionality to the dpkg crew for a while. It will arrive someday. Right. -- Thomas Adam -- Frankly, Mr. Shankly, since you ask. You are a flatulent pain in the arse. -- Morrissey. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 01:54:41PM +0100, Thomas Adam wrote: On Tue, Aug 24, 2004 at 08:49:57AM -0400, Jason Rennie wrote: dpkg -S | --search filename-search-pattern ... Search for a filename from installed packages. How is this unclear, exactly? It doesn't say, Search for a filename THAT IS CONTAINED WITHIN an installed package. Why wouldn't the above include programmatically-generated configuration files? They're from the package. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com Why just use our trusty old friend find? also you have locate, whereis, and a bunch of others, I must say find can do about anything. Also whereis is a nice catch all for common files and programs. It seems that you need to use the right tool for the job, and frankly I don't see dpkg -S as a good solution. It works for packages that dpkg knows about. But then that could be said of the same for rpm -qf. Rthoreau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 09:22:16AM -0500, Rthoreau wrote: Why just use our trusty old friend find? Because the question is Which package was responsible for creating this conffile? How can find answer that? -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
I wrote: Just off the top of my head I see no reason why these files [created by maintainer scripts] could not be included in the package empty and filled in by the scripts. This would identify the files as belonging to the package and also allow dpkg to remove them, eliminating the need for the postrm to do so. Thomas Adam writes: The overhead in doing this is stupid... A few dozen bytes in each of those few packages that need it, less any reduction in the postinst and postrm. ...and having a lot of empty files in /etc is just pointless. Where would any empty files come from? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Henrique de Moraes Holschuh writes: Actually, we have been requesting this functionality to the dpkg crew for a while. It will arrive someday. The idea is that we will register dynamically-created stuff with a package in the maintainer script. That's a good solution. It deals with the possibility that files might be conditionally created. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Rthoreau writes: Why just use our trusty old friend find? also you have locate, whereis, and a bunch of others, I must say find can do about anything. How do you propose to get find to tell you which files were created by a particular package, or which package created a particular file? File names often have no obvious connection to the package that created them. It seems that you need to use the right tool for the job, and frankly I don't see dpkg -S as a good solution. It works for packages that dpkg knows about. The subject is files created by packages installed by dpkg. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Thomas Adam [EMAIL PROTECTED] writes: On Tue, Aug 24, 2004 at 09:24:45AM -0400, Carl Fink wrote: On Tue, Aug 24, 2004 at 01:54:41PM +0100, Thomas Adam wrote: On Tue, Aug 24, 2004 at 08:49:57AM -0400, Jason Rennie wrote: dpkg -S | --search filename-search-pattern ... Search for a filename from installed packages. How is this unclear, exactly? It doesn't say, Search for a filename THAT IS CONTAINED WITHIN an installed package. Why wouldn't the above include programmatically-generated configuration files? They're from the package. They're not from any package -- they're created by programs that are themselves from packages. Are configuration files that cannot be associated with exactly one package all that common? I would have thought that most configuration files that are not in a package are created (and removed) by the maintainer scripts of exactly one package. In this case, it would certainly (IMHO) make sense to have a way by which the name of the package can be queried. For the user, the mechanism which has created the file may be less important than the information which package is responsible for the file. But how on Earth can you keep information as to programs that created files? One possibility would be that the maintainer script which creates the file stores the filename in something like /var/lib/dpkg/info/PACKAGE.createdfiles. It's a stupid and pointless exercise. I don't agree. Martin -- ,--. ,= ,-_-. =. / ,- )Martin Dickopp, Dresden, Germany((_/)o o(\_)) \ `-'http://www.zero-based.org/`-'(. .)`-' `-. \_/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Martin writes: One possibility would be that the maintainer script which creates the file stores the filename in something like /var/lib/dpkg/info/PACKAGE.createdfiles. Gaak! No! The archive must _only_ be accessed via the packaging system tools. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler [EMAIL PROTECTED] wrote: ...and having a lot of empty files in /etc is just pointless. Where would any empty files come from? How should a package tell dpkg to install an empty file, if it needs that? Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 10:18:08PM +0800, John Summerfield wrote: Seems to me the idea of creating configuration files on the fly is broken. I much prefer this: Yes, so how exactly, for example, is phpmyadmin supposed to touch files, such as httpd.conf, so that it works and is properly configured *when it is installed*? Hmm? If httpd.conf was owned by apache, no other package could touch it (I think we all agree allowing this would be a mess), how can it modify the file to allow itself to work? The is why some configuration files are created upon installation and not owned by any package. So we have a tradeoff. I prefer having to do a little hunting to figure out which package created the file than, as on a SuSE or Red Hat system, have completely misconfigured software all over the system. You ignore the fact that almost all red hat packages, when installed, are broken. I think that is a far bigger problem. You are forgetting that Debian has taken the packaging system far, far beyond anything Red Hat or SuSE have done. -- _ _ _ _ _ _ _ _ _ _ _ _ _ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ ( t | i | m | @ | i | t | . | k | p | t | . | c | c ) \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ GPG key fingerprint = 1DEE CD9B 4808 F608 FBBF DC21 2807 D7D3 09CA 85BF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
John Hasler [EMAIL PROTECTED] writes: Martin writes: One possibility would be that the maintainer script which creates the file stores the filename in something like /var/lib/dpkg/info/PACKAGE.createdfiles. Gaak! No! The archive must _only_ be accessed via the packaging system tools. I didn't mean to imply otherwise. In this scenario, the maintainer scripts would modify the .createdfiles file through packaging system tools. Come to think of it, the .createdfiles file could even be a static part of the package. If it contains a list of all files the maintainer scripts /potentially/ create, it wouldn't need to be modified at all. Even if /var/lib/dpkg/info is not the right place, my point still stands that it would technically feasible to maintain such a list of created files for each package. :) Martin -- ,--. ,= ,-_-. =. / ,- )Martin Dickopp, Dresden, Germany((_/)o o(\_)) \ `-'http://www.zero-based.org/`-'(. .)`-' `-. \_/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 11:35:28AM -0500, Tim Kelley wrote: On Tue, Aug 24, 2004 at 10:18:08PM +0800, John Summerfield wrote: Seems to me the idea of creating configuration files on the fly is broken. I much prefer this: Yes, so how exactly, for example, is phpmyadmin supposed to touch files, such as httpd.conf, so that it works and is properly configured *when it is installed*? Hmm? If httpd.conf was owned by apache, no other package could touch it (I think we all agree allowing this would be a mess), how can it modify the file to allow itself to work? The is why some configuration files are created upon installation and not owned by any package. So we have a tradeoff. I prefer having to do a little hunting to figure out which package created the file than, as on a SuSE or Red Hat system, have completely misconfigured software all over the system. You ignore the fact that almost all red hat packages, when installed, are broken. I think that is a far bigger problem. You are forgetting that Debian has taken the packaging system far, far beyond anything Red Hat or SuSE have done. It appears that there are two distinct roles for packages with respect to files: 1 the .deb of the package contains an initial copy of the file 2 the package programs/scripts are permitted/expected to maintain and update the file as needed. It is unually assumed that only one package may play either of these roles with respect to a given file, and that it should be the same package for a given file. But httpd.conf seems to be a counter example for role 2. That only one package may play Role 2 w.r.t. a given file is Debian policy only for files that are served Role 1 by that same package. When the httpd.conf situation arises, the Debian way seems to be that a package constructs an initial copy of the file on the fly, rather than containing an initial copy. Thus, the file is built by the package but not owned by the package. This may sound goofy to outsiders, but it preserves the primacy of policy while solving a practical problem. However, there is a problem waiting for a smart lawyer to exploit: There is nothing in these rules that precludes some arbitrary new package from touching httpd.conf for some purpose of its own that has nothing to do with the proper operation of a web server system. What does keep this from happening is the good sense of Debian maintainers. Until someone can come up with a plausible example of why it might thought reasonable to have some other package, mutt, for example, touch httpd.conf maybe we can avoid adding more rules to policy. But if a new ruled are needed, consider defining groups of packages that own a particular file as tenants in common or as joint tenants. The existence of these groups would have to be documented somehow, and the programs written to maintain the documentation. It sounds like a lot of work for very little gain. -- Paul E Condon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Tim Kelley wrote: On Tue, Aug 24, 2004 at 10:18:08PM +0800, John Summerfield wrote: Seems to me the idea of creating configuration files on the fly is broken. I much prefer this: Yes, so how exactly, for example, is phpmyadmin supposed to touch files, such as httpd.conf, so that it works and is properly configured *when it is installed*? Hmm? If httpd.conf was owned by apache, no other package could touch it (I think we all agree allowing this would be a mess), how can it modify the file to allow itself to work? The is why some configuration files are created upon installation and not owned by any package. /etc/httpd/conf/conf.d Something workable seems done in Apache2. It wouldn't be hard to build a temp config on the fly in a similar way to how modutils works: concatenatea bunch of partial files to create one single file. A proforma or empty httpd.conf would be shipped. So we have a tradeoff. I prefer having to do a little hunting to figure out which package created the file than, as on a SuSE or Red Hat system, have completely misconfigured software all over the system. You ignore the fact that almost all red hat packages, when installed, are broken. I think that is a far bigger problem. You are forgetting that Debian has taken the packaging system far, far beyond anything Red Hat or SuSE have done. How broken? I agree Debian was once the leader, but I think that's no longer the case. How long since you actually tried RH or SuSE products? I think several aspects of Debian behaviour are ill-conceived: 1. That I want to start a daemon as soon as I've installed it Typically I want to install at the office, configure in the field. 2. That I want to configure software when I install it. Typically I want to read the (gasp) documentation. 3. That if I have KDE|GNOME|whatever DTE installed I always want to run it when I boot. For various reason I sometimes want to boot to an otherwise fully functioning system without gooey stuff. For example, KDE hangs one partituclar system I have if it sees real hardware. Under VNC it's fine. 4. That I know where in the startup/shutdown process each daemon belongs. On RHL SuSE if I decide to turn ptal off because my printeris causing grief, it's a simple command to do so. Later, I can easily turn it back on in its proper place in the startup sequence. -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Wed, Aug 25, 2004 at 08:57:42AM +0800, John Summerfield wrote: 1. That I want to start a daemon as soon as I've installed it Typically I want to install at the office, configure in the field. So download the files but don't complete the install until you're in the field. The -d flag to apt-get. 2. That I want to configure software when I install it. Typically I want to read the (gasp) documentation. So skip the configuration step and use dpkg--reconfigure later. 3. That if I have KDE|GNOME|whatever DTE installed I always want to run it when I boot. Okay, that annoys me, too. 4. That I know where in the startup/shutdown process each daemon belongs. On RHL SuSE if I decide to turn ptal off because my printeris causing grief, it's a simple command to do so. Later, I can easily turn it back on in its proper place in the startup sequence. I don't understand this. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Paul E Condon wrote: It appears that there are two distinct roles for packages with respect to files: 1 the .deb of the package contains an initial copy of the file 2 the package programs/scripts are permitted/expected to maintain and update the file as needed. It is unually assumed that only one package may play either of these roles with respect to a given file, and that it should be the same package for a given file. But httpd.conf seems to be a counter example for role 2. That only one package may play Role 2 w.r.t. a given file is Debian policy only for files that are served Role 1 by that same package. When the httpd.conf situation arises, the Debian way seems to be that a package constructs an initial copy of the file on the fly, rather than containing an initial copy. Thus, the file is built by the package but not owned by the package. This may sound goofy to outsiders, but it preserves the primacy of policy while solving a practical problem. However, there is a problem waiting for a smart lawyer to exploit: There is nothing in these rules that precludes some arbitrary new package from touching httpd.conf for some purpose of its own that has nothing to do with the proper operation of a web server system. What does keep this from happening is the good sense of Debian maintainers. Until someone can come up with a plausible example of why it might thought reasonable to have some other package, mutt, for example, touch httpd.conf maybe we can avoid adding more rules to policy. Policy isa fine thing where it facilitates getting the job at hand done. When it gets in the way, then the policy needs review. But if a new ruled are needed, consider defining groups of packages that own a particular file as tenants in common or as joint tenants. The existence of these groups would have to be documented somehow, and the programs written to maintain the documentation. It sounds like a lot of work for very little gain. You will find certain directories owned by an enormous number of packages. In the particular case of Apache, it seems to me there could be a standard httpd.conf with standard optional components defined but perhaps commented out. There could be a standard way of activating those components when an optional module, say webdav, is installed, deactivating them when it's removed. This is not very different from the way inetd.conf works. A separate application, such as pgpgroupware, which requires significant configuration changes to Apache, should (as phpgroupware does) contain its own configuration file. The active httpd.conf needs to be modified to the extent of adding an include statement when the application is to be activated (which, I might add, is _not_ when it's installed!). -- Cheers John -- spambait [EMAIL PROTECTED] [EMAIL PROTECTED] Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 09:06:50PM -0400, Carl Fink wrote: 3. That if I have KDE|GNOME|whatever DTE installed I always want to run it when I boot. Okay, that annoys me, too. rcconf is quite handy. But removing the symlinks in /etc/rc?.d/* for whatever DM is running, or editing /etc/X11/default-display-manager (again, we've been over this before), is nothing trivial. 4. That I know where in the startup/shutdown process each daemon belongs. On RHL SuSE if I decide to turn ptal off because my printeris causing grief, it's a simple command to do so. Later, I can easily turn it back on in its proper place in the startup sequence. I don't understand this. See rcconf, above. That's possibly what he's getting at. -- Thomas Adam -- Quis custodiet ipsos custodes? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
Thomas Adam writes: ...But removing the symlinks in /etc/rc?.d/* for whatever DM is running... If you remove them they will be recreated when you upgrade the package. Sysvconfig allows you to disable stuff. Just select Enable/Disable in the main menu and follow directions. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg / apt equivalent to 'rpm -qf'?
On Tue, Aug 24, 2004 at 06:00:47PM +0200, Frank Küster wrote: John Hasler [EMAIL PROTECTED] wrote: ...and having a lot of empty files in /etc is just pointless. Where would any empty files come from? How should a package tell dpkg to install an empty file, if it needs that? Regards, Frank Hi Frank, man touch -Kev -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ Have you mooed today?... signature.asc Description: Digital signature
Re: rpm packages Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Aug 12, 2004 at 02:41:08PM -0400, [EMAIL PROTECTED] wrote: I have 2 rpm packages that I want to install on a Sarge system. Can someone give me a hint or a link as to how to do that. Michael Hi M, the first rule of DEBIAN club is to use .debs first! so, first have you used : apt-cache search XYZ to see it is in your current repository list. If not, check the debian site to see if it is in another version of debian. If not, ask here if a debian version exists somewhere else! if all else fails, use 'alien'! -Kev PS. there is also a way you can help debian. if you think this software is important to you, you can ask that some debian developer consider making a brand new .deb of this software! It may be something other debian users would want. - -- (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ Have you mooed today?... -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBHF6kAWAAuqdWA9cRAvfMAJwNvxD0u8/UEtWsJf+dM4T+tznb5gCePrd1 n6Y1qG1LVTqEpnye823roEQ= =Kyh0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
rpm packages Debian
I have 2 rpm packages that I want to install on a Sarge system. Can someone give me a hint or a link as to how to do that. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rpm packages Debian
On Thu, 2004-08-12 at 14:41, [EMAIL PROTECTED] wrote: I have 2 rpm packages that I want to install on a Sarge system. Can someone give me a hint or a link as to how to do that. Michael Try alien -i filename.rpm signature.asc Description: This is a digitally signed message part
Re: rpm packages Debian
[EMAIL PROTECTED] writes: I have 2 rpm packages that I want to install on a Sarge system. Can someone give me a hint or a link as to how to do that. alien might be able to convert them to .debs for you. pgpieaqieoalo.pgp Description: PGP signature
Re: rpm packages Debian
On August 12, 2004 02:41 pm, [EMAIL PROTECTED] wrote: I have 2 rpm packages that I want to install on a Sarge system. Can someone give me a hint or a link as to how to do that. Michael You can convert them to debs using alien command and then install the debs: apt-get install alien alient --to-deb *.rpm dpkg -i *.deb Cheers, Peter www.dialore.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RPM kontra DEB
Dzięki. Właśnie o apt-file mi chodziło. apt-file update szuka plików Contents.gz, w których jest zawarty spis plików pakietów. Jednakże mam płytę DVD z Debian Sarge z Linux Magazine i niestety apt-file nie znajduje tam tego pliku (Contents*), więc nie może odczytać listy plików. Czy można jakoś utworzyć plik (Contents) z pakietów tej płyty wykorzystując narzedzia APT, podobnie jak można utworzyć plik Packages przy uzyciu dpkg-scanpackages? Pozdr. ajbm
RE: rpm sorunu
On Fri, 2004-06-11 at 01:57 +0300, Selçuk SARAÇ wrote: Roots.gen.tr'ın A adresi 1.2.3.4 Ve roots.gen.tr'ın MX adresi 5.6.7.8 Fakat sarge üzerindeki postfix e-mail'i göndermek için 1.2.3.4'e bağlanmaya çalışıyor... /etc/hosts dosyanız Postfix'i yanıltıyor olmalı. -- __ | | | | Enver ALTIN (a.k.a. skyblue) | | Software developer, IT consultant |FRONT | |==| FrontSITE Bilgi Teknolojisi A.Ş. |_SITE_| http://www.frontsite.com.tr/ signature.asc Description: This is a digitally signed message part
RE: rpm sorunu
Selamlar; Sarge üzerinde hiç bu sorunu yaşayan var mı bilmiyorum ama garip bir problem yaşıyorum. Sarge default kurulumu yapıyorum, exim4'ü iptal ederek postfix default kurulum gerçekleştiriyorum. Deneme amaçlı bir e-mail gönderiyorum, gönderilen adres - [EMAIL PROTECTED] Roots.gen.tr'ın A adresi 1.2.3.4 Ve roots.gen.tr'ın MX adresi 5.6.7.8 Fakat sarge üzerindeki postfix e-mail'i göndermek için 1.2.3.4'e bağlanmaya çalışıyor... İlk düşüncem postfix'de bir hata mı var? Silip exim ile denediğimde sonuç aynı. Exim'i de silip postfix'i manual olarak derlediğimde de sonuç aynı... Sanırım bütün garip hatalar beni buluyor... Bu sorunu daha önce yaşamış veya fikri olan var mı? İyi çalışmalar; Selçuk SARAÇ +- // sadecehosting.com
Re: RPM kontra DEB
On Tue, 8 Jun 2004, [EMAIL PROTECTED] wrote: Wiele razy słyszałem opinie nad wyższością deb-ów nad rpm-ami. A ja słyszałem rzecz wręcz naprzeciwną i to od osoby, która się z pewnością na tym zna (Sergiusz Pawłowicz). Wawrzek -- Wawrzyniec NiewodniczańskiE-MAIL: niewod(at)kicia.ch.pwr.wroc.pl vel LarryN WWW:http://ch.pwr.wroc.pl/~niewod/en-index.php PhD student @JID: [EMAIL PROTECTED] Wroclaw University of TechnologyTEL: +48(071)320-2894
RPM kontra DEB
Wiele razy słyszałem opinie nad wyższością deb-ów nad rpm-ami. Lecz RPM-y w aktualnej wersji możliwości mają zbliżone do deb-ów. Również mogą być aktualizowane z różnych źródeł, (np. ftp, http, cdrom, dysk twardy), działa sprawdzanie zależności, instalowanie zależnych pakietów... Jest również możliwość zobaczenia, jakie pliki wchodzą w skład niezainstalowanego pakietu bez konieczności wrzucania płytki z tym pakietem - sprawdzałem w kpackage. Często ta właściwość jest przydatna, gdy szukam jakiegoś pliku, a nie wiem w jakim pakiecie go znaleźć. Gdy w Debianie w kpackage przeglądałem pakiety DEB, to zawartość (pliki) pakietów pokazywał tylko w przypadku tych zainstalowanych, natomiast gdy chcialem zobaczyć, co znajduje się w pakiecie, który nie jest zainstalowany, to wyświetlało tylko opis, bez listy plików wchodzących w jego skład. czy to znaczy, że nie ma możliwości podejrzenia tych plików? APT nie zapisuje gdzieś listy plików oprócz opisu pakietu? A poze po prostu coś źle patrzę? Może jakiś inny program pozwala na zobaczenie zawartości niezainstalowanych pakietów DEB bez konieczności wkładania płytki, bądź łączenia się z siecią w celu ściągnięcia danego deb-a?
Re: RPM kontra DEB
On Tue, 8 Jun 2004 19:00:11 +0200 [EMAIL PROTECTED] wrote: Wiele razy słyszałem opinie nad wyższością deb-ów nad rpm-ami. Lecz RPM-y w aktualnej wersji możliwości mają zbliżone do deb-ów. Również mogą być aktualizowane z różnych źródeł, (np. ftp, http, cdrom, dysk twardy), działa sprawdzanie zależności, instalowanie zależnych pakietów... To raczej 'ficzery' nakładek (apt, yum itp.), bo jeśli chodzi o deby i rpmy to od dawna mają zbliżone możliwości. Jest również możliwość zobaczenia, jakie pliki wchodzą w skład niezainstalowanego pakietu bez konieczności wrzucania płytki z tym pakietem - sprawdzałem w kpackage. Często ta właściwość jest przydatna, gdy szukam jakiegoś pliku, a nie wiem w jakim pakiecie go znaleźć. Zdaj się, że apt-file to robi. Chyba 'troszkę' przegiąłeś z zawijaniem linii - okropnie wygląda twój mail... Spokojnie możesz do siedemdziesięciukilku znaków dojechać. Nie ustawiaj nagłówka Reply-To:, bo nie można normalnie na listę odpowiadać. Ech, The Bat! to rzeczywiście najgorszy mailer... Karol -- | Karol Czachorowski narel(at)fantastyka.net | | JID: narel(at)jabber.org GG: 2786028 |
Re: RPM kontra DEB
On Tue, Jun 08, 2004 at 07:00:11PM +0200, [EMAIL PROTECTED] wrote: Wiele razy słyszałem opinie nad wyższością deb-ów nad rpm-ami. Tak samo jak wiele razy ja słyszałem odwrotne ;) Lecz RPM-y w aktualnej wersji możliwości mają zbliżone do deb-ów. Również mogą być aktualizowane z różnych źródeł, (np. ftp, http, cdrom, dysk twardy), To akurat nie ma nic wspólnego z rodzajem pakietów, a raczej oprogramowaniem do ich zarządzania... bo sam pakiet raczej niewiele wie o tym w jaki sposób się dostał do komputera ;) działa sprawdzanie zależności, instalowanie zależnych pakietów... No to dość naturalne dla każdego systemu pakietów. Jest również możliwość zobaczenia, jakie pliki wchodzą w skład niezainstalowanego pakietu bez konieczności wrzucania płytki z tym pakietem - sprawdzałem w kpackage. Często ta właściwość jest przydatna, gdy szukam jakiegoś pliku, a nie wiem w jakim pakiecie go znaleźć. Gdy w Debianie w kpackage przeglądałem pakiety DEB, to zawartość (pliki) pakietów pokazywał tylko w przypadku tych zainstalowanych, natomiast gdy chcialem zobaczyć, co znajduje się w pakiecie, który nie jest zainstalowany, to wyświetlało tylko opis, bez listy plików wchodzących w jego skład. czy to znaczy, że nie ma możliwości podejrzenia tych plików? APT nie zapisuje gdzieś listy plików oprócz opisu pakietu? A poze po prostu coś źle patrzę? Może jakiś inny program pozwala na zobaczenie zawartości niezainstalowanych pakietów DEB bez konieczności wkładania płytki, bądź łączenia się z siecią w celu ściągnięcia danego deb-a? `apt-get install apt-file` `apt-file update` `apt-file list mój ulubiony pakiet` pozdr, fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: Debian, rpm and corporate world
Thus spake dircha: # Paul Johnson wrote: # What's wrong with, Make me a Debian package or lose a customer? # # I'd venture to guess: # We're sorry, but we can not presently justify the costs of maintaining a # Debian port. Perhaps if one of our larger customers express an interest # in it... If an ISV really had to maintain packages of their proprietary software for every possible distro their customers may be using it probably would be quite time consuming. Actually, probably the best way for an ISV to distribute their proprietary software would be in something like makeself or their own proprietary equivalent. It could be made to check for its dependencies based on the files (not packages) installed on the system, and it could even automatically download and/or install the packages it needs based on the distro if they so desire. This would truly be a cross-distro package. It wouldn't have to rely on a distro, debian or otherwise, to be properly installed and fully functional. This would be by far the best way for vendors to release their software, because it wouldn't matter what Linux their customers are using. PRINCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world
Jaldhar H. Vyas [EMAIL PROTECTED] writes: On Tue, 18 May 2004, Paul Johnson wrote: Anything proprietary is automatically a toy to me. ...which is why your opinion is utterly worthless. I'm not asking anyone to like proprietary software or the corporate environment but at least know your enemy if nothing else. I know my enemy. I'm stuck in a Windows environment at work, and unfortunately I'm nowhere near the decision making process on that. I'm not impressed. -- Paul Johnson [EMAIL PROTECTED] Linux. You can find a worse OS, but it costs more. pgpqFgFmlCq10.pgp Description: PGP signature
Re: Debian, rpm and corporate world
Incoming from Paul Johnson: dircha [EMAIL PROTECTED] writes: Paul Johnson wrote: What's wrong with, Make me a Debian package or lose a customer? I'd venture to guess: We're sorry, but we can not presently justify the costs of maintaining a Debian port. Perhaps if one of our larger customers express an interest in it... So don't tollerate clueless vendors. Go find someone else. If you're Paul's Boss: Paul, we need to install Oracle. Do it. Paul: They don't make a Debian port. Pick something else. Paul's Boss: Eh? Somebody wanna get Paul out of here? I've had enough of him. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world
Paul Johnson wrote: My understanding is this is a vocal minority decreasing in size as more good, free software comes out. You are thinking perhaps of of office productivity software? Proprietary software is sort of a band-aid for a real solution, or a toy for after work. A toy for after work, like a game? Hahaha! That is a good one. Check out these two prominant, non-oracle examples. Both high profile chip design software companies. And they don't come cheap. You won't see any prices there. Ever eat in a restaurant with no prices on the menu? It's kind'a like that. These are fairly representative of my corporate world. http://www.cadence.com/support/computing/32bit.aspx http://www.synopsys.com/products/platforms_roadmap.html Interesting, rarely do companies like these deliver rpms. Instead they usually have custom installation scripts for their tar files. This comes because they install on HP-UX and Solaris well before being ported to our favorite system. Bob pgpqbcBWkM8Nu.pgp Description: PGP signature
Re: Debian, rpm and corporate world
On Tuesday 18 May 2004 07:00, Paul Johnson wrote: Wow, Ian's being rather optimistic in thinking that RPM can overcome it's own shortcomings to stop sucking. Such as, 1) distro-dependent RPMs, RPM isn't standardized like Deb is. 2) Naming conventions. RPM isn't standardized. 3) Per-file dependencies need to be eliminated in RPM, it's a major contributor to problems 1 and 2. 4) QA in RPM based distros is apparently non-existent, contributing to problems 1, 2 and 3 and making headlines as it does. Aren't 1 and 2 caused largely by the fact that several different distros use and produce RPMs whereas (as far as I know) only Debian uses deb packages and people produce them specifically for Debian? (I'm not trying to stir up trouble: please correct me if I'm wrong.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world
On Tuesday 18 May 2004 07:00, Paul Johnson wrote: Dominique Dumont wrote: [EMAIL PROTECTED] (Bob Proulx) writes: #rpm -ivh myproduct-xxx-xx.rpm As other people have written doing this is not a good thing. Put yourself in the other position. I have a .deb file from Debian. I want to install it on a RH system. Should I insist that you must use dpkg to install it there? That would be just as silly as insisting the reverse. A native packaging is always best. Sure. Be if one can easily install rpm packages on a Debian system, this would be a good message sent to the corporate world. Ian Murdock [EMAIL PROTECTED] wrote the following a while back. I am very interested in how it turns out. http://lists.progeny.com/archive/discover-workers/200310/msg0.html Summary snippet: We are also working with various parties to add/merge RPM support into the mainline APT, to allow Debian- and RPM-based distributions to be managed using a single APT codebase, and possibly even to allow Debian and RPM packages to coexist side by side. This work also aims to merge our various APT extensions (e.g., support for authenticated APT repos) into the mainline APT. Wow, Ian's being rather optimistic in thinking that RPM can overcome it's own shortcomings to stop sucking. Such as, 1) distro-dependent RPMs, RPM isn't standardized like Deb is. 2) Naming conventions. RPM isn't standardized. 3) Per-file dependencies need to be eliminated in RPM, it's a major contributor to problems 1 and 2. 4) QA in RPM based distros is apparently non-existent, contributing to problems 1, 2 and 3 and making headlines as it does. The clean fix would be to go back in time, kill the people who thought RPM was a good idea and make sure the Debian folks do what they did anyway, but we can't have everything. 8:o) Currently there is big chicken and egg problem with Debian in the corporate world. Corporate guys want to be able to install software from ISV (like Oracle). I understand what you are saying. But they can install oracle and others today. My comment is that they want a vendor supported installation of the vendor application. Not an installation that a Debian expert made happen. It's 2004. Linux is the second most common OS and Debian is the distro with the largest Linux market share from what I've been hearing lately. There is *ZERO* excuse for companies supporting Linux not to have .debs if they're distributing in binary form, they need to Debianize or hit the grave. If you alien the RH package and try to install it on Debian it will install fine. Programs will work. But then eventually you will install a Debian package which requires not ncurses4 but libncurses4. Number 2 and Number 4 from above apply. Personally, yes. I think many people have that ideal. It is written into the Social Contract. But the recent Debian Social Contract vote casts that as a majority opinion into doubt. So now I don't know. A contingent of vocal DDs would certainly say no. My understanding is this is a vocal minority decreasing in size as more good, free software comes out. Proprietary software is sort of a band-aid for a real solution, or a toy for after work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Connors [EMAIL PROTECTED] writes: Paul Johnson [EMAIL PROTECTED] said on Mon, 17 May 2004 22:37:44 -0700: dircha [EMAIL PROTECTED] writes: I'd venture to guess: We're sorry, but we can not presently justify the costs of maintaining a Debian port. Perhaps if one of our larger customers express an interest in it... So don't tollerate clueless vendors. Go find someone else. If you're going to spend money on software, why spend it on software that sucks? Because all software sucks. And if it doesn't the hardware sucks. And if *it* doesn't, then the firmware must surely suck. Debian. Because software doesn't have to suck. http://debian.org/ - -- Paul Johnson [EMAIL PROTECTED] Linux. You can find a worse OS, but it costs more. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAqcbZUzgNqloQMwcRAvtHAKCy3izKDTh0nx9r0JX0xWT5x6CWmgCggoho szDXB5fv6fqzTpwmGhricR4= =yOyg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world (was: Can rpm packages from other linux distribution be used on Debian?)
on Mon, May 17, 2004 at 11:07:01AM +0200, Dominique Dumont ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] (Bob Proulx) writes: and I found that it can't find files it need in deb DB,I had been tried to install it on debian, #rpm -ivh myproduct-xxx-xx.rpm the program will prompt: myproduct need perl 5.6, and the bash must be installed As other people have written doing this is not a good thing. Put yourself in the other position. I have a .deb file from Debian. I want to install it on a RH system. Should I insist that you must use dpkg to install it there? That would be just as silly as insisting the reverse. A native packaging is always best. Currently there is big chicken and egg problem with Debian in the corporate world. Corporate guys want to be able to install software from ISV (like Oracle). Oracle, and a small number of related enterprise systems, really sit in a class by themselves. Ideally, they're installed on stand-alone, dedicated hardware, with the OS tweaked to the application's specification. Had an interesting discussion a few weeks back with a friend now working at PeopleSoft, tracing kernel issues through the application. For applications of this complexity, scope, and corporate profile, you pretty much _do_ knuckle down. Doesn't mean you can't play around the edges, or investigate alternatives. And for a wide class of applications (again: SAS in my experience), the so-called distro-specificity is pretty much a red herring. Though your support contract may call for it. In practice, the truth is that the Unix share of such ISV's operations is falling drastically. SAS now splits revenues between MF and 'Doze, with 'Nix a rapidly declining share (another reason I find it far less interesting these days). ISVs only provide their proprietary software as rpm because not many corporation ask for Debian. Corporation do not ask for Debian because most ISVs don't provide Debian packages. Last time I installed Oracle, it was some gawdoffal Java-based GUI installation. Granted, 2000/2001. Is there an RPM yet? IMHO, the only way to break this circle is to provide a way to install rpm that doesn't look like a hack. It's not a hack, it's an alien ;-) Peace. -- Karsten M. Self [EMAIL PROTECTED]http://kmself.home.netcom.com/ What Part of Gestalt don't you understand? Save Bob Edwards! http://www.savebobedwards.com/ signature.asc Description: Digital signature
Re: Debian, rpm and corporate world
Paul Johnson [EMAIL PROTECTED] said on Mon, 17 May 2004 22:37:44 -0700: dircha [EMAIL PROTECTED] writes: I'd venture to guess: We're sorry, but we can not presently justify the costs of maintaining a Debian port. Perhaps if one of our larger customers express an interest in it... So don't tollerate clueless vendors. Go find someone else. If you're going to spend money on software, why spend it on software that sucks? Because all software sucks. And if it doesn't the hardware sucks. And if *it* doesn't, then the firmware must surely suck. -- TimC -- http://astronomy.swin.edu.au/staff/tconnors/ The prolonged application of polysyllabic vocabulary infallibly exercises a deleterious influence on the fecundity of expression, rendering the ultimate tendancy apocryphal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world
On Tue, 18 May 2004, Paul Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Connors [EMAIL PROTECTED] writes: Because all software sucks. And if it doesn't the hardware sucks. And if *it* doesn't, then the firmware must surely suck. Debian. Because software doesn't have to suck. http://debian.org/ Sigh. woosh. http://www.faqs.org/docs/jargon/A/All-hardware-sucks-all-software-sucks.html -- TimC -- http://astronomy.swin.edu.au/staff/tconnors/ Can you keep your witty comments shorter dude? I can't make that my sig! --Hipatia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world
[EMAIL PROTECTED] (Bob Proulx) writes: Currently there is big chicken and egg problem with Debian in the corporate world. Corporate guys want to be able to install software from ISV (like Oracle). I understand what you are saying. But they can install oracle and others today. My comment is that they want a vendor supported installation of the vendor application. Not an installation that a Debian expert made happen. Exactly. If you alien the RH package and try to install it on Debian it will install fine. Programs will work. But then eventually you will install a Debian package which requires not ncurses4 but libncurses4. The names won't match. If you try to install libncurses4 it will have file conflicts with ncurses4. If you try to remove ncurses4 first you will have dependencies problems. Anything built with ncurses4 installed won't know about libncurses4. Yes, this is all from personal experience. I created my own problems by not following the right policy. How do you propose to handle this type of case? Note that I am not disagreeing in principle to the fact that this would be beneficial. I agree with that. I am just asking how would this actually be done. I do not think it is possible. But I am very happy if I am proved wrong. IMHO, packages names and packages versions are only some kind of shrink-wrap for the distributed files. Dependency problems boil down to the fact that a file version x depends on a set of files of version x,y,z. So, the only common ground between distro are the files names and location and upstream version. So we must work on that. One way to solve the problem you mention is to fall back on checking the dependencies wrt the content of the packages (i.e the files). E.g: - foo.rpm requires libncurses4.rpm. - no libncurses4.deb is found - some rpm database (on disk or on-line ?) is queried for the content of libncurses4.rpm - some rules (to be defined ...) are applied to avoid requiring unnecessary files (like package doc ?) - Debian database is queried for missing files, ncurses4.deb and bar.deb (for the same of the example) contain these files - install ncurses4.deb and bar.deb - install foo.rpm The file dependency checking must be completely done by the tool. We can't ask people to interfere in this area, this is too complex. This approach raises some non-obvious problems: - the rpm database must refer to a well-known and maintained rpm repository with some consistent naming policy (Suse ?) - the files are installed in standard location independent of the distro (LSB compliance ?) - there must be a consistent way to identify the upstream version of each package (rpm or deb), lest version dependencies will not be satisfied [ I not sure that I have proved you wrong yet ... ;-) ] - Can tool like 'drpm' be reliable enough ? Look to 'alien' for the best track record we have so far for this type of tool. The answer is, Not yet. Alien does a decent conversion job. Except for the dependency part. Cheers -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world
Adam Funk [EMAIL PROTECTED] writes: Wow, Ian's being rather optimistic in thinking that RPM can overcome it's own shortcomings to stop sucking. Such as, 1) distro-dependent RPMs, RPM isn't standardized like Deb is. 2) Naming conventions. RPM isn't standardized. 3) Per-file dependencies need to be eliminated in RPM, it's a major contributor to problems 1 and 2. 4) QA in RPM based distros is apparently non-existent, contributing to problems 1, 2 and 3 and making headlines as it does. Aren't 1 and 2 caused largely by the fact that several different distros use and produce RPMs whereas (as far as I know) only Debian uses deb packages and people produce them specifically for Debian? (I'm not trying to stir up trouble: please correct me if I'm wrong.) I think that the main problem comes from the fact that several different distros use and produce RPMs without a common policy. The Debian policy is where Debian project is really brilliant. Thanks to all people involved for respecting it. Cheers -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world
Incoming from Adam Funk: use and produce RPMs whereas (as far as I know) only Debian uses deb packages and people produce them specifically for Debian? (I'm not That's arguable. There's Debian, and then there's Knoppix, Morphix, Libranet, Lindows, ... -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world
[EMAIL PROTECTED] (Bob Proulx) writes: Paul Johnson wrote: My understanding is this is a vocal minority decreasing in size as more good, free software comes out. You are thinking perhaps of of office productivity software? Proprietary software is sort of a band-aid for a real solution, or a toy for after work. A toy for after work, like a game? Hahaha! That is a good one. Anything proprietary is automatically a toy to me. Whether it clasically falls into the definition of a toy like Vice City does or a toy in the sense that Citrix Maincrash does, it doesn't matter. If it's proprietary, it's deliberately a toy like Vice City, or it's a toy by accident like Citrix Mainblame is. I hate Citrix with passion at this point. Yeah, Vice City automatically sucks because it's not GPL, but at least your job doesn't depend on Vice City working right. Check out these two prominant, non-oracle examples. Both high profile chip design software companies. And they don't come cheap. You won't see any prices there. Ever eat in a restaurant with no prices on the menu? It's kind'a like that. These are fairly representative of my corporate world. No prices on the menu? That's retarded. -- Paul Johnson [EMAIL PROTECTED] Linux. You can find a worse OS, but it costs more. pgpb6ZSvhLxbO.pgp Description: PGP signature
Re: Debian, rpm and corporate world
Adam Funk [EMAIL PROTECTED] writes: On Tuesday 18 May 2004 07:00, Paul Johnson wrote: Wow, Ian's being rather optimistic in thinking that RPM can overcome it's own shortcomings to stop sucking. Such as, 1) distro-dependent RPMs, RPM isn't standardized like Deb is. 2) Naming conventions. RPM isn't standardized. 3) Per-file dependencies need to be eliminated in RPM, it's a major contributor to problems 1 and 2. 4) QA in RPM based distros is apparently non-existent, contributing to problems 1, 2 and 3 and making headlines as it does. Aren't 1 and 2 caused largely by the fact that several different distros use and produce RPMs whereas (as far as I know) only Debian uses deb packages and people produce them specifically for Debian? (I'm not trying to stir up trouble: please correct me if I'm wrong.) RPMs have been distro-specific since at least 1998, probably before that. -- Paul Johnson [EMAIL PROTECTED] Linux. You can find a worse OS, but it costs more. pgp37xZ6mJets.pgp Description: PGP signature
Re: Debian, rpm and corporate world
s. keeling [EMAIL PROTECTED] writes: Incoming from Adam Funk: use and produce RPMs whereas (as far as I know) only Debian uses deb packages and people produce them specifically for Debian? (I'm not That's arguable. There's Debian, and then there's Knoppix, Morphix, Libranet, Lindows, ... And the vast majority of the time, using a Deb from one doesn't break anything in another. -- Paul Johnson [EMAIL PROTECTED] Lin You can find a worse OS, but it costs more. pgppQY717Xeei.pgp Description: PGP signature
Re: Debian, rpm and corporate world
On Tue, 18 May 2004, Paul Johnson wrote: Anything proprietary is automatically a toy to me. ...which is why your opinion is utterly worthless. I'm not asking anyone to like proprietary software or the corporate environment but at least know your enemy if nothing else. Mindless zealotry does more to harm successful advocacy than not mentioning Debian at all. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world (was: Can rpm packages from other linux distribution be used on Debian?)
On Mon, 17 May 2004, Dominique Dumont wrote: Sure. Be if one can easily install rpm packages on a Debian system, this would be a good message sent to the corporate world. I don't think so. The kind of corporate type who even know there is such a difference will understand why .debs are better. The ones who don't will never get the message. Currently there is big chicken and egg problem with Debian in the corporate world. Corporate guys want to be able to install software from ISV (like Oracle). Oracle is a bad example. Corporate DBAs pick whatever platform Oracle supports. Oracle will never support Debian not because there's no one there who knows how to make a .deb but because it is to chaotic for their tech support model. ISVs only provide their proprietary software as rpm because not many corporation ask for Debian. Corporation do not ask for Debian because most ISVs don't provide Debian packages. Corporations do not ask for Debian because it is not on Oracles (or other ISVs) supported platform list. The operating system is just a commodity. It's the apps that drive the platform not the other way around. So the trick is to convince the ISVs that apps are worth porting to Debian. Once they are convinced, they'll work out how to make .debs fast enough. IMHO, the only way to break this circle is to provide a way to install rpm that doesn't look like a hack. I disagree. IMO the number one thing we can do to drum up ISV support is to hurry up and release sarge. Woody is so out of date it's a maintainence nightmare. For example the latest stable versions of SUSE and Fedora are using perl 5.8.x. Woody still has 5.6. There are enough minor differences between the two to significantly complicate QA work. And lets not even talk about things like g++ or NPTL. Two, customers (as opposed to random zealots on mailing lists) need to be really vocal about wanting genuine Debian support. Everytime you get a survey, write about wanting Debian support. Everytime you meet a sales rep, ask him so hows the Debian support coming? When ISVs sense genuine demand, they will figure out how to fill it. Three, we need to increase the amount of documentation for developers and users. The more Debian is a known quantity, the easier it will be for ISVs to work with it and around it. So to sum up, don't worry about package format. It's really not important at all. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian, rpm and corporate world (was: Can rpm packages from other linux distribution be used on Debian?)
[EMAIL PROTECTED] (Bob Proulx) writes: and I found that it can't find files it need in deb DB,I had been tried to install it on debian, #rpm -ivh myproduct-xxx-xx.rpm the program will prompt: myproduct need perl 5.6, and the bash must be installed As other people have written doing this is not a good thing. Put yourself in the other position. I have a .deb file from Debian. I want to install it on a RH system. Should I insist that you must use dpkg to install it there? That would be just as silly as insisting the reverse. A native packaging is always best. Sure. Be if one can easily install rpm packages on a Debian system, this would be a good message sent to the corporate world. Currently there is big chicken and egg problem with Debian in the corporate world. Corporate guys want to be able to install software from ISV (like Oracle). ISVs only provide their proprietary software as rpm because not many corporation ask for Debian. Corporation do not ask for Debian because most ISVs don't provide Debian packages. IMHO, the only way to break this circle is to provide a way to install rpm that doesn't look like a hack. The example above rpm -ivh myproduct-xxx-xx.rpm would be perfect. The trick is that rpm need not to be the genuine rpm. It could be a program that would call alien, check the dependencies and then call dpkg. Or Debian could provide a 'drpm' that would do the same thing. The name is close enough to genuine rpm to give the feeling that yes, it's supported (it is also indeed a matter of subjective feeling) The major difficulty is: the installation must check the dependencies expressed in the rpm package by using the data stored in the Debian package database. Without a dependency check, installing a big product like Oracle will not be easy. So the questions are now: - does the Debian community want Debian to be used in corporate world to run *proprietary* softwares ? - Can tool like 'drpm' be reliable enough ? Cheers -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world
Dominique Dumont [EMAIL PROTECTED] writes: Currently there is big chicken and egg problem with Debian in the corporate world. Corporate guys want to be able to install software from ISV (like Oracle). ISVs only provide their proprietary software as rpm because not many corporation ask for Debian. Corporation do not ask for Debian because most ISVs don't provide Debian packages. IMHO, the only way to break this circle is to provide a way to install rpm that doesn't look like a hack. What's wrong with, Make me a Debian package or lose a customer? -- Paul Johnson [EMAIL PROTECTED] Linux. You can find a worse OS, but it costs more. pgpfDz4eFWI6f.pgp Description: PGP signature
Re: Debian, rpm and corporate world
Paul Johnson wrote: Dominique Dumont [EMAIL PROTECTED] writes: Currently there is big chicken and egg problem with Debian in the corporate world. Corporate guys want to be able to install software from ISV (like Oracle). ISVs only provide their proprietary software as rpm because not many corporation ask for Debian. Corporation do not ask for Debian because most ISVs don't provide Debian packages. IMHO, the only way to break this circle is to provide a way to install rpm that doesn't look like a hack. What's wrong with, Make me a Debian package or lose a customer? I'd venture to guess: We're sorry, but we can not presently justify the costs of maintaining a Debian port. Perhaps if one of our larger customers express an interest in it... dircha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world (was: Can rpm packages from other linux distribution be used on Debian?)
Dominique Dumont wrote: [EMAIL PROTECTED] (Bob Proulx) writes: #rpm -ivh myproduct-xxx-xx.rpm As other people have written doing this is not a good thing. Put yourself in the other position. I have a .deb file from Debian. I want to install it on a RH system. Should I insist that you must use dpkg to install it there? That would be just as silly as insisting the reverse. A native packaging is always best. Sure. Be if one can easily install rpm packages on a Debian system, this would be a good message sent to the corporate world. Ian Murdock [EMAIL PROTECTED] wrote the following a while back. I am very interested in how it turns out. http://lists.progeny.com/archive/discover-workers/200310/msg0.html Summary snippet: We are also working with various parties to add/merge RPM support into the mainline APT, to allow Debian- and RPM-based distributions to be managed using a single APT codebase, and possibly even to allow Debian and RPM packages to coexist side by side. This work also aims to merge our various APT extensions (e.g., support for authenticated APT repos) into the mainline APT. It is our hope that a distribution-independent Anaconda and a distribution-independent APT (plus, eventually, a distribution- independent configuration framework) will, along with a stronger LSB, help unify further the various Linux distributions. So there is hope for your goal. But it is not here yet. A problem to be handled will be different distro policies. Look at the recent issues just discussed about installing and maintaining KNOPPIX on a hard drive. A fine system. Based on Debian. But still there are issues about interoperating packages. If something that close can't work transparently how well can packages crossing really different distros operate? I am skeptical. But cautiously hopeful. Currently there is big chicken and egg problem with Debian in the corporate world. Corporate guys want to be able to install software from ISV (like Oracle). I understand what you are saying. But they can install oracle and others today. My comment is that they want a vendor supported installation of the vendor application. Not an installation that a Debian expert made happen. ISVs only provide their proprietary software as rpm because not many corporation ask for Debian. Corporation do not ask for Debian because most ISVs don't provide Debian packages. We ask routinely. We get stone-walled routinely. But we do it anyway. However we have a lot of in house Debian expertise at my place of employment. Enough that vendor support was not the biggest lever. We do keep one RH machine (one vendor's supported platform, I am in the USA) so that when we need to bring a vendor in on a problem we recreate the problem there. Problems have always been identical in behavior on Debian systems too. But the vendor won't acknowledge it until we can get them a test case on their system. And by that I mean a system on the vendor's developer's machine. In the end I think we just need to wear down the folks supporting a particular distro instead of supporting GNU/Linux in general. And I am starting to see headway with our vendors. But it is slow going. IMHO, the only way to break this circle is to provide a way to install rpm that doesn't look like a hack. I previously gave one example of the MTA differences between distros. But let's take something simple which might seem reasonable to alien install like ncurses4, /usr/lib/libncurses.so.4. A common compatibility library needed for many RH programs to run on Debian. Woody does not have this. I think potato did and it was dropped and is now back in sarge. If you alien the RH package and try to install it on Debian it will install fine. Programs will work. But then eventually you will install a Debian package which requires not ncurses4 but libncurses4. The names won't match. If you try to install libncurses4 it will have file conflicts with ncurses4. If you try to remove ncurses4 first you will have dependencies problems. Anything built with ncurses4 installed won't know about libncurses4. Yes, this is all from personal experience. I created my own problems by not following the right policy. How do you propose to handle this type of case? Note that I am not disagreeing in principle to the fact that this would be beneficial. I agree with that. I am just asking how would this actually be done. I do not think it is possible. But I am very happy if I am proved wrong. So the questions are now: - does the Debian community want Debian to be used in corporate world to run *proprietary* softwares ? Personally, yes. I think many people have that ideal. It is written into the Social Contract. But the recent Debian Social Contract vote casts that as a majority opinion into doubt. So now I don't know. A contingent of vocal DDs would certainly say no. - Can tool like 'drpm
Re: Debian, rpm and corporate world (was: Can rpm packages from other linux distribution be used on Debian?)
On Mon, May 17, 2004 at 04:10:39PM -0600, Bob Proulx wrote: Dominique Dumont wrote: So the questions are now: - does the Debian community want Debian to be used in corporate world to run *proprietary* softwares ? Personally, yes. I think many people have that ideal. It is written into the Social Contract. But the recent Debian Social Contract vote casts that as a majority opinion into doubt. So now I don't know. A contingent of vocal DDs would certainly say no. I don't think the recent Social Contract vote affected that, really. The discussion has been almost entirely about what Debian should ship, not what our users should be able to do. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian, rpm and corporate world
dircha [EMAIL PROTECTED] writes: Paul Johnson wrote: Dominique Dumont [EMAIL PROTECTED] writes: Currently there is big chicken and egg problem with Debian in the corporate world. Corporate guys want to be able to install software from ISV (like Oracle). ISVs only provide their proprietary software as rpm because not many corporation ask for Debian. Corporation do not ask for Debian because most ISVs don't provide Debian packages. IMHO, the only way to break this circle is to provide a way to install rpm that doesn't look like a hack. What's wrong with, Make me a Debian package or lose a customer? I'd venture to guess: We're sorry, but we can not presently justify the costs of maintaining a Debian port. Perhaps if one of our larger customers express an interest in it... So don't tollerate clueless vendors. Go find someone else. If you're going to spend money on software, why spend it on software that sucks? -- Paul Johnson [EMAIL PROTECTED] Linux. You can find a worse OS, but it costs more. pgp49yGjc66Kk.pgp Description: PGP signature
Re: Debian, rpm and corporate world
[EMAIL PROTECTED] (Bob Proulx) writes: Dominique Dumont wrote: [EMAIL PROTECTED] (Bob Proulx) writes: #rpm -ivh myproduct-xxx-xx.rpm As other people have written doing this is not a good thing. Put yourself in the other position. I have a .deb file from Debian. I want to install it on a RH system. Should I insist that you must use dpkg to install it there? That would be just as silly as insisting the reverse. A native packaging is always best. Sure. Be if one can easily install rpm packages on a Debian system, this would be a good message sent to the corporate world. Ian Murdock [EMAIL PROTECTED] wrote the following a while back. I am very interested in how it turns out. http://lists.progeny.com/archive/discover-workers/200310/msg0.html Summary snippet: We are also working with various parties to add/merge RPM support into the mainline APT, to allow Debian- and RPM-based distributions to be managed using a single APT codebase, and possibly even to allow Debian and RPM packages to coexist side by side. This work also aims to merge our various APT extensions (e.g., support for authenticated APT repos) into the mainline APT. Wow, Ian's being rather optimistic in thinking that RPM can overcome it's own shortcomings to stop sucking. Such as, 1) distro-dependent RPMs, RPM isn't standardized like Deb is. 2) Naming conventions. RPM isn't standardized. 3) Per-file dependencies need to be eliminated in RPM, it's a major contributor to problems 1 and 2. 4) QA in RPM based distros is apparently non-existent, contributing to problems 1, 2 and 3 and making headlines as it does. The clean fix would be to go back in time, kill the people who thought RPM was a good idea and make sure the Debian folks do what they did anyway, but we can't have everything. 8:o) Currently there is big chicken and egg problem with Debian in the corporate world. Corporate guys want to be able to install software from ISV (like Oracle). I understand what you are saying. But they can install oracle and others today. My comment is that they want a vendor supported installation of the vendor application. Not an installation that a Debian expert made happen. It's 2004. Linux is the second most common OS and Debian is the distro with the largest Linux market share from what I've been hearing lately. There is *ZERO* excuse for companies supporting Linux not to have .debs if they're distributing in binary form, they need to Debianize or hit the grave. If you alien the RH package and try to install it on Debian it will install fine. Programs will work. But then eventually you will install a Debian package which requires not ncurses4 but libncurses4. Number 2 and Number 4 from above apply. Personally, yes. I think many people have that ideal. It is written into the Social Contract. But the recent Debian Social Contract vote casts that as a majority opinion into doubt. So now I don't know. A contingent of vocal DDs would certainly say no. My understanding is this is a vocal minority decreasing in size as more good, free software comes out. Proprietary software is sort of a band-aid for a real solution, or a toy for after work. -- Paul Johnson [EMAIL PROTECTED] Linux. You can find a worse OS, but it costs more. pgpnd0g5WzM0j.pgp Description: PGP signature
Re: Can rpm packages from other linux distribution be used on Debian?
On Wed, May 12, 2004 at 05:40:51PM +0800, Rick wrote: Hello People: Our product is base on redhat,I will porting it to Debian,but in this system,many procedure depend redhat rpms,for example: glibc-2.3.2-11.9.i386.rpm, perl-5.8.0-88.i386.rpm,etc.. At the start,I wanted to try install these rpm packages(from redhat) On debian,but I found that thers is a lot work to do,some rpm packages even can't be installed on it.(perhaps these rpms packages from redhat can't be used on debian at all).I think 2 ways to settle this problem,But I am not sure these ways is doable,and I wish to get some advices about it.these problem are: 1. Use a certain tool to translate these packages(glibc*.rpm..) from redhat to rpm packages that can be used on debian.Is there such tools exist on debian? 2. On Debian,after I install rpm,rpm DB and deb DB exist,Can I make some mapping bettwen betwwen rpm DB and deb DB? when I run rpm command,the OS will invoke debian DB.for example: # rpm -qv gcc package gcc is not installed #dpkg -l |grep gcc ii gcc-3.03.0.4-7The GNU C compiler. # this means gcc*rpm isn't installed but gcc*deb is installed on debian. after I make this mapping,I can use rpm to access deb DB. # rpm -qv gcc gcc-3.0 # if this way is feasible,How to do it? I am a new debian user,not too familiar with this OS, If above ways are impossible,is thers other ways to attain my purpose? As someone else mentioned, look at the alien Debian package for conversion from .rpm .deb. But that is hardly adequate for reliable, professional software. You should consider a more realistic option: 3. Genuinely *port* your software to the Debian platform. While glibc 2.3.2 and perl 5.8 are not available in the current Debian stable release (Woody), it's rather unlikely that your software *needs* those components in those versions - i.e. whether it is more or less a matter of recompiling. But then you know that. Or even if not this, somehow you're going to need to provide security updates for these libraries your software needs. These packages aren't going to reliably install with alien or rpm unmodified. So if you're going to officially support the port of your software to Debian (which seems to be part of the definition of port), you are going to need to distribute these packages to your users yourselves, and distribute security updates of these non-official packages yourselves. Since you will be doing this anyhow, why not simply maintain these packages as .deb packages in the versions your users will need, in the form of backports [1] for Debian stable (Woody)? [1] http://www.backports.org dircha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can rpm packages from other linux distribution be used on Debian?
On Sat, May 15, 2004 at 01:16:09AM -0400, Kevin Mark wrote: On Fri, May 14, 2004 at 09:50:00PM -0600, s. keeling wrote: I imagine there are cases in which this approach won't work, but we see the same thing from people everyday who are limiting themselves to only using debian tools. Just look at that stable vs. testing vs. unstable thread a month ago. And that's possibly the worst news the original poster wants to hear; he's got to make his stuff work on stable, testing, and unstable?!? Gah! Hi S, one doesnt make a product 'work' for stable, testing or unstable. every package start out it life as an unstable package. And if it proves its stability it will get moved to testing. And then if all goes well, it moves into stable. its stability and interaction with other packages are the criteria that the debian packager of an authors work uses to judge when it is moved to the next phase of readyness for 'stable'. That applies to Debian packages, but not to third-party products being ported to Debian. The usual approach for those is to build for stable and deal with other problems if and when they arise. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can rpm packages from other linux distribution be used on Debian?
On Friday 14 May 2004 11:19 pm, Paul E Condon wrote: packages because the Debian community believes its deb packaging system is superior to the rpm system.* Debian also has a social commitment to free * Actually, it _is_ superior, but I'm trying to be nice. Vastly so. No need to be nice about it. The wRetched Package Manager just needs to go away. :) -- Michael McIntyre Silvan [EMAIL PROTECTED] Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can rpm packages from other linux distribution be used on Debian?
On Saturday 15 May 2004 01:16 am, Kevin Mark wrote: its stability it will get moved to testing. And then if all goes well, it moves into stable. its stability and interaction with other packages are the criteria that the debian packager of an authors work uses to judge when it is moved to the next phase of readyness for 'stable'. Well, that's all rather misleading, I think. Nothing ever makes it into stable. When stable is stable, stable stays stable. When was the last time a package made it from Sid into Woody? The descriptions of the Debian Way make it sound like that happens, but it doesn't. Packages make it into stable all at once, and after they're there, they're frozen in time forever. Security and bug fixes, yes, but the version of libflummy is chiseled in stone pretty much for eternity thereafter. The way this is usually described just doesn't reflect the reality of it. -- Michael McIntyre Silvan [EMAIL PROTECTED] Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can rpm packages from other linux distribution be used on Debian?
Incoming from Silvan: On Friday 14 May 2004 11:19 pm, Paul E Condon wrote: packages because the Debian community believes its deb packaging system is superior to the rpm system.* Debian also has a social commitment to free * Actually, it _is_ superior, but I'm trying to be nice. Vastly so. No need to be nice about it. The wRetched Package Manager just needs to go away. :) Could you do World Peace first? It might be easier. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can rpm packages from other linux distribution be used on Debian?
s. keeling wrote: Incoming from Silvan: On Friday 14 May 2004 11:19 pm, Paul E Condon wrote: packages because the Debian community believes its deb packaging system is superior to the rpm system.* Debian also has a social commitment to free * Actually, it _is_ superior, but I'm trying to be nice. Vastly so. No need to be nice about it. The wRetched Package Manager just needs to go away. :) Could you do World Peace first? It might be easier. There could be no World Peace while RPM exists freely and is so widely supported by fanatical users with no regard for ease of use or superior methods. We simply can not compromise! -- Damon L. Chesser [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Can rpm packages from other linux distribution be used on Debian?
Rick wrote: Yes,I think so.but our procedure depend rpm format, I think you are confusing a packaging format with your program. You program undoubtedly depends upon shared libraries and other things. But it is packaged into a distribution format. It can be packaged into many different formats. and I found that it can't find files it need in deb DB,I had been tried to install it on debian, #rpm -ivh myproduct-xxx-xx.rpm the program will prompt: myproduct need perl 5.6, and the bash must be installed As other people have written doing this is not a good thing. Put yourself in the other position. I have a .deb file from Debian. I want to install it on a RH system. Should I insist that you must use dpkg to install it there? That would be just as silly as insisting the reverse. A native packaging is always best. A real example might help. On Debian only one MTA (mail transport agents) can be installed at the same time. Installing a different one pushes out the previous one. This makes it easy to switch between MTAs. Just install a different one. Have sendmail installed? Install postfix. Sendmail is removed as Postfix is added leaving Postfix as the active MTA. Want to go back? Install the previous MTA of choice. Everything works. It is very nice. On later RH they use the alternatives for /usr/sbin/mta making it a symlink to the currently active MTA such as one of sendmail or postfix. It is possible to have multiple MTAs installed but only one of them active[1]. This is a completely different method of managing the current MTA. And after installation you must adjust the alternatives and other things or your desired selected MTA is not configured. On RH 7.3 (don't know about later versions) postfix has a lower priority than sendmail for example. Installing a package from a different system will not be written to handle the other system's management methods. This is completely outside the scope of just a package installation tool like dpkg or rpm or even a dependency aware tool like apt or yum but encompasses the larger problem of system policy. There are issues of naming conventions and other such things to be taken into consideration. I feel that the system policy which describes how packages interoperate is where Debian is clearly ahead of the competition. Bob [1] Why have multiple MTAs installed? Only one can really be active. It just causes problems. But this is legacy from RH usage. On RH at bare metal install time is the only time you can guarantee the dependencies are all resolvable. So RH users have been encouraged to install everything from the CD at installation time regardless of the sensibility of that because later they won't be able to do so. This required RH to facilitate this using the Debian alternatives as a way to have multiple MTAs installed at the same time but only one operating. I see that as a hack on a hack. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can rpm packages from other linux distribution be used on Debian?
Incoming from Damon L. Chesser: There could be no World Peace while RPM exists freely and is so widely supported by fanatical users with no regard for ease of use or superior methods. We simply can not compromise! Ah, geez. A day doesn't go by lately that someone isn't declaring war on somebody.:-P I have Applix on my machine. It installed off their CD in rpm format. It works fine in Woody. It worked fine on SuSE when I was running that. In other words, we can all just get along. Besides, we've already got enough top-posters to be consigned to Hell before we bite off more problems. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Can rpm packages from other linux distribution be used on Debian?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thus spake Rick: # #rpm -ivh myproduct-xxx-xx.rpm # the program will prompt: myproduct need perl 5.6, and the bash must be installed # In fact,the 2 debian packages has been installed,I think rpm command will read info from only rpm DB on debian. This is generally not recommended, but the easiest thing to do would be to simply add the --nodeps option on the command line: rpm -ivh myproduct-xxx-xx.rpm --nodeps If all dependencies are installed in Debian, you will find that the newly installed RPM package will run flawlessly. The RPM dependency check is only done at install time, not at runtime. The package will also be uninstalled properly without complaining about dependencies: rpm -e myproduct HTH, PRINCE -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFApSOnAl2SNUPt1I8RAgilAJ95ku4xjb1QBgQg29xyMAhVuUmNjQCfdhkS 6jV/7y+kHNT1zpEttmkWKlE= =lbVA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can rpm packages from other linux distribution be used on Debian?
On Wed, May 12, 2004 at 05:40:51PM +0800, Rick wrote: Hello People: Our product is base on redhat,I will porting it to Debian,but in this system,many procedure depend redhat rpms,for example: glibc-2.3.2-11.9.i386.rpm, perl-5.8.0-88.i386.rpm,etc.. At the start,I wanted to try install these rpm packages(from redhat) On debian,but I found that thers is a lot work to do,some rpm packages even can't be installed on it.(perhaps these rpms packages from redhat can't be used on debian at all).I think 2 ways to settle this problem,But I am not sure these ways is doable,and I wish to get some advices about it.these problem are: 1. Use a certain tool to translate these packages(glibc*.rpm..) from redhat to rpm packages that can be used on debian.Is there such tools exist on debian? 2. On Debian,after I install rpm,rpm DB and deb DB exist,Can I make some mapping bettwen betwwen rpm DB and deb DB? when I run rpm command,the OS will invoke debian DB.for example: # rpm -qv gcc package gcc is not installed #dpkg -l |grep gcc ii gcc-3.03.0.4-7The GNU C compiler. # this means gcc*rpm isn't installed but gcc*deb is installed on debian. after I make this mapping,I can use rpm to access deb DB. # rpm -qv gcc gcc-3.0 # if this way is feasible,How to do it? I am a new debian user,not too familiar with this OS, If above ways are impossible,is thers other ways to attain my purpose? Rick, Debian is a GNU/Linux distribution in its own right. It does not use rpm packages because the Debian community believes its deb packaging system is superior to the rpm system.* Debian also has a social commitment to free software, which may have some effect on the viability of your project to port a product to Debian. But if you are committed to the port, and if you want to present your product in a way that it has its best chance to be accepted in this market, you should create a Debian package for it. Rpm packages do not play well with Debian. Most Debian users would simply reject a product that is not properly packaged for Debian. Some might try to use it. Some might get it to work. Some might even like it. But then those few will ask you to package it as a deb before they buy. The rest will ignore your stuff. You might as well be a Czech asking a Frenchman to learn Czech just so he can use your software, which is written with all Czech prompts and documentation. Best of Luck -- Paul E Condon [EMAIL PROTECTED] * Actually, it _is_ superior, but I'm trying to be nice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can rpm packages from other linux distribution be used on Debian?
Incoming from Paul E Condon: On Wed, May 12, 2004 at 05:40:51PM +0800, Rick wrote: Our product is base on redhat,I will porting it to Debian,but in this system,many procedure depend redhat rpms,for example: glibc-2.3.2-11.9.i386.rpm, perl-5.8.0-88.i386.rpm,etc.. Some might try to use it. Some might get it to work. Some might even like it. But then those few will ask you to package it as a deb before they buy. The rest will And others will use rpm for rpms and Debian tools for .debs, including alien to convert one to the other, or simply installing whatever we've got to work with. I imagine there are cases in which this approach won't work, but we see the same thing from people everyday who are limiting themselves to only using debian tools. Just look at that stable vs. testing vs. unstable thread a month ago. And that's possibly the worst news the original poster wants to hear; he's got to make his stuff work on stable, testing, and unstable?!? Gah! -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can rpm packages from other linux distribution be used on Debian?
On Fri, May 14, 2004 at 09:50:00PM -0600, s. keeling wrote: Incoming from Paul E Condon: On Wed, May 12, 2004 at 05:40:51PM +0800, Rick wrote: Our product is base on redhat,I will porting it to Debian,but in this system,many procedure depend redhat rpms,for example: glibc-2.3.2-11.9.i386.rpm, perl-5.8.0-88.i386.rpm,etc.. Some might try to use it. Some might get it to work. Some might even like it. But then those few will ask you to package it as a deb before they buy. The rest will And others will use rpm for rpms and Debian tools for .debs, including alien to convert one to the other, or simply installing whatever we've got to work with. I imagine there are cases in which this approach won't work, but we see the same thing from people everyday who are limiting themselves to only using debian tools. Just look at that stable vs. testing vs. unstable thread a month ago. And that's possibly the worst news the original poster wants to hear; he's got to make his stuff work on stable, testing, and unstable?!? Gah! -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - Hi S, one doesnt make a product 'work' for stable, testing or unstable. every package start out it life as an unstable package. And if it proves its stability it will get moved to testing. And then if all goes well, it moves into stable. its stability and interaction with other packages are the criteria that the debian packager of an authors work uses to judge when it is moved to the next phase of readyness for 'stable'. -Kev signature.asc Description: Digital signature
Re: Re : Porter des rpm sous debian : quelle est la meilleure methode ?
Salut, Je pense qu'avec ces deux documents là, tu ne devrais pas avoir de problèmes. En fait, c'est assez facile de faire un paquet pour quelque chose qu'on a écrit soit même, car la principale difficulté est de maîtriser le Makefile pour le rendre debian compliant. Debian Binary Package Building HOWTO http://www.tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/ Guide du nouveau responsable Debian http://www.debian.org/doc/maint-guide/ A+ Olivier -- Laboratoire de Mathématiques, Applications et Physique Mathématique d'Orléans UMR 6628 - Université d'Orléans - B.P. 6759 - 45067 Orléans Cedex 2 E-Mail: [EMAIL PROTECTED] http://www.univ-orleans.fr/SCIENCES/MAPMO/membres/garet/
Re: rpm and Debian
Rick wrote: Can I use rpm command to access deb DB? rpm is available in the Debian package of the same name (rpm). However, any packages you install with the rpm command will not be managed by the Debian package management system. .deb is the native package format of a Debian system. You can attempt to convert .rpm packages to .deb packages using the tools available in the alien package. However, conversion will not always be successful and may not produce the results you expect. It is best to install software on your Debian system from .deb packages. If you can not locate a .deb package for the software you wish to install in the official Debian repositories [1], you can also try apt-get.org [2] for third-party apt repositories of all types or backports.org [3] for third-party apt repositories for the stable distribution only. If you need assistance configuring your system to install software, feel free to consult the Debian manual [4], search the list archives [5], or ask here on the list. [1] http://packages.debian.org [2] http://apt-get.org [3] http://www.backports.org [4] http://www.debian.org/doc/debian-policy/ [5] http://lists.debian.org dircha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rpm and Debian
On Thu, 13 May 2004 00:58:58 -0500 dircha [EMAIL PROTECTED] wrote: [1] http://packages.debian.org [2] http://apt-get.org [3] http://www.backports.org [4] http://www.debian.org/doc/debian-policy/ [5] http://lists.debian.org Not to forget http://mentors.debian.net You might be able to find packages which are not available at the official repository. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rpm and Debian
On Thu, May 13, 2004 at 03:32:57PM -0400, Lee Hanxue wrote: On Thu, 13 May 2004 00:58:58 -0500 dircha [EMAIL PROTECTED] wrote: [1] http://packages.debian.org [2] http://apt-get.org [3] http://www.backports.org [4] http://www.debian.org/doc/debian-policy/ [5] http://lists.debian.org Not to forget http://mentors.debian.net You might be able to find packages which are not available at the official repository. I would advise against using mentors.debian.net unless you're a Debian developer sponsoring packages, or unless somebody you trust has explicitly pointed you to an individual package there. Packages in the mentors archive are there because they're waiting for a Debian developer to sponsor them into the official archive. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
- porter des rpm sous debian - alien : faire des tar ou des .deb ?
Bonjour la liste ! Je dois porter un bon paquet de package rpm vers du debian et je me demande un peu comment faire. Apres etude de la question il s'avere qu'alien correspond bien a mon probleme mais j aimerai avoir votre avis sur la methode operatoire precise : faut il mieux passer par des tar ou par des deb ? Apres avoir essaye avec des deb il s'avere que lors de l installation des packages deb generes il fait un peu n importe quoi, genre il se contente de faire des tar a la racine. Du coup je me suis reporte a l'option -t d'alien (faire des tar) puis apres je decrypte le fichier en .spec pour connaitre les details de l'installation rpm et faire de meme sous ma debian. C'est un poil fastidieux (decryptage de fichier *.spec pas toujours marrant) mais ca a le merite d'etre, je pense, fonctionnel a la fin. Cependant je suis un peu perplexe car je me demande pourquoi alien fait par defaut des .deb si c'est tant la galere... Avez vous des idees, suggestions, remarques ou critiques ? Merci d'avance ! Joseph
Porter des rpm sous debian : quelle est la meilleure methode ?
Bonjour Je me permets de reposter sur ce sujet qui m'interesse particulierement : quelle est selon vous la meilleure facon de porter des rpm sous debian (en vue d'en faire un jour eventuellement des .deb)? Dans un premier temps je me contente de tout installer (via les src.rpm) et pour cela j'utilise alien -t (pour faire des tar), qu'en dites vous ? Merci d'avance Joseph ps : desole d'insister -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re: Re : Porter des rpm sous debian : quelle est la meilleure methode ?
Salut Ben en fait je participe (en tant que stagiaire) a un projet qui etait avant base sous Red Hat et qui doit etre porte sous Debian (il s'agit d'Access Grid, www.accessgrid.org, un outil de visioconference et de grid computing). Ce fameux Access Grid n'existe pas pour l'instant en package debian... ++ Joseph On Thu, 13 May 2004 02:11:14 +0200, Edi STOJICEVIC [EMAIL PROTECTED] wrote: Le 13.05.2004 01:47:42, Joseph a écrit : Bonjour Salut, Je me permets de reposter sur ce sujet qui m'interesse particulierement : quelle est selon vous la meilleure facon de porter des rpm sous debian (en vue d'en faire un jour eventuellement des . deb)? Dans un premier temps je me contente de tout installer (via les src. rpm) et pour cela j'utilise alien -t (pour faire des tar), qu'en dites vous ? Sous Debian, tu as plus de 1 packages !? cela m'étonnerait fortement que tu ne trouves pas ton bonheur là-dedans :-) Merci d'avance De rien Joseph ES -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Re : Porter des rpm sous debian : quelle est la meilleure methode ?
Le 13.05.2004 01:47:42, Joseph a écrit : Bonjour Salut, Je me permets de reposter sur ce sujet qui m'interesse particulierement : quelle est selon vous la meilleure facon de porter des rpm sous debian (en vue d'en faire un jour eventuellement des . deb)? Dans un premier temps je me contente de tout installer (via les src. rpm) et pour cela j'utilise alien -t (pour faire des tar), qu'en dites vous ? Sous Debian, tu as plus de 1 packages !? cela m'étonnerait fortement que tu ne trouves pas ton bonheur là-dedans :-) Merci d'avance De rien Joseph ES
rpm sorunu
Woody i ilk kez kurdum ve rpm paketlerini kurmaya çalıştığımda aşağıdaki hata mesajını aldım error: cannot open Packages index using db3 - No such file or directory (2)error: cannot open Packages database in /var/lib/rpm rpm initdb ve rpm rebuilddb kullanmayı denedim fakat yine aynı problemi yaşadım. Yardımcı olabilecek arkadaş varsa sevinirim.Herkese iyi çalışmalar.
Re: rpm sorunu
Debian'in standart paket sistemi deb'tir. rpm paketlerin kurulumu sorun yaratir. illaki rpm kumak istiyorsaniz. oncelikle alien kurun: apt-get install alien daha sonra rpm paketinizi asagida komutla deb formatina cevirin: alien --to-deb package.rpm ve dpkg -i package.deb ama internet baglantiniz iyiyse sistemizi testing veya unstable olarak guncelleyip debian'in 15000 civarindaki yuksek kaliteli paketlerini kullanabilirsiniz. On Wed, 2004-05-12 at 15:47, Onur BİNGÜL wrote: Woody ‘i ilk kez kurdum ve rpm paketlerini kurmaya çalıştığımda aşağıdaki hata mesajını aldım error: cannot open Packages index using db3 - No such file or directory (2) error: cannot open Packages database in /var/lib/rpm rpm –initdb ve rpm –rebuilddb kullanmayı denedim fakat yine aynı problemi yaşadım. Yardımcı olabilecek arkadaş varsa sevinirim.Herkese iyi çalışmalar. -- Selman ULUG [EMAIL PROTECTED]
Re: rpm sorunu
alien`la deb`e cevririp bir de oyle kurmayi dene - Original Message - From: Onur BİNGÜL To: debian-user-turkish@lists.debian.org Sent: Wednesday, May 12, 2004 3:47 PM Subject: rpm sorunu Woody i ilk kez kurdum ve rpm paketlerini kurmaya çalıştığımda aşağıdaki hata mesajını aldımerror: cannot open Packages index using db3 - No such file or directory (2)error: cannot open Packages database in /var/lib/rpm rpm initdb ve rpm rebuilddb kullanmayı denedim fakat yine aynı problemi yaşadım. Yardımcı olabilecek arkadaş varsa sevinirim.Herkese iyi çalışmalar.
Re: rpm sorunu
* Onur BİNGÜL [2004-05-12 15:47:02+0300] Woody 'i ilk kez kurdum ve rpm paketlerini kurmaya çalıştığımda aşağıdaki hata mesajını aldım error: cannot open Packages index using db3 - No such file or directory (2) error: cannot open Packages database in /var/lib/rpm rpm -initdb ve rpm -rebuilddb kullanmayı denedim fakat yine aynı problemi yaşadım. Yardımcı olabilecek arkadaş varsa sevinirim.Herkese iyi çalışmalar. :-) Oldu mu ama simdi, sen Cimbom'un sahasinda Fener'lik yapmissin. Aman mazaallah :-) Debian'da kullanilan paket bicemi RPM degil DEB'dir. Kurmaya calistigin program her ne ise onun bir .deb paketi mutlaka vardir. Ustelik kurulumu o sekilde 'rpm -i ...' ile apt-get ile yapmak gibi pratik bir yontem de var. Sisteme APT kaynaklarini tanitmak icin (root olarak): apt-setup komutunu calistirin ve uygun kaynaklari girin. Sayet paket kaynagi olarak CD kullaniyorsaniz bu CD'leri sisteme tanitmalisiniz mesela. Tatminkar bir Internet baglantiniz varsa FTP yontemi olarak su kaynagi girebilirsiniz: ftp.tr.debian.org Bu on ayardan sonra: apt-get update ile paket listesini alin/guncelleyin. Mesela mozilla'yi: apt-get install mozilla gibi bir komutla kurun. Kolay gelsin, -- roktas
Re: rpm sorunu
sonucta fener sampiyon olmustur. yasasin debian (biraz alakasiz oldu ama) On Wed, 2004-05-12 at 16:27, Recai Oktas wrote: * Onur BİNGÜL [2004-05-12 15:47:02+0300] Woody 'i ilk kez kurdum ve rpm paketlerini kurmaya çalıştığımda aşağıdaki hata mesajını aldım error: cannot open Packages index using db3 - No such file or directory (2) error: cannot open Packages database in /var/lib/rpm rpm -initdb ve rpm -rebuilddb kullanmayı denedim fakat yine aynı problemi yaşadım. Yardımcı olabilecek arkadaş varsa sevinirim.Herkese iyi çalışmalar. :-) Oldu mu ama simdi, sen Cimbom'un sahasinda Fener'lik yapmissin. Aman mazaallah :-) Debian'da kullanilan paket bicemi RPM degil DEB'dir. Kurmaya calistigin program her ne ise onun bir .deb paketi mutlaka vardir. Ustelik kurulumu o sekilde 'rpm -i ...' ile apt-get ile yapmak gibi pratik bir yontem de var. Sisteme APT kaynaklarini tanitmak icin (root olarak): apt-setup komutunu calistirin ve uygun kaynaklari girin. Sayet paket kaynagi olarak CD kullaniyorsaniz bu CD'leri sisteme tanitmalisiniz mesela. Tatminkar bir Internet baglantiniz varsa FTP yontemi olarak su kaynagi girebilirsiniz: ftp.tr.debian.org Bu on ayardan sonra: apt-get update ile paket listesini alin/guncelleyin. Mesela mozilla'yi: apt-get install mozilla gibi bir komutla kurun. Kolay gelsin, -- roktas -- Selman ULUG [EMAIL PROTECTED]
Can rpm packages from other linux distribution be used on Debian?
Hello People: Our product is base on redhat,I will porting it to Debian,but in this system,many procedure depend redhat rpms,for example: glibc-2.3.2-11.9.i386.rpm, perl-5.8.0-88.i386.rpm,etc.. At the start,I wanted to try install these rpm packages(from redhat) On debian,but I found that thers is a lot work to do,some rpm packages even can't be installed on it.(perhaps these rpms packages from redhat can't be used on debian at all).I think 2 ways to settle this problem,But I am not sure these ways is doable,and I wish to get some advices about it.these problem are: 1. Use a certain tool to translate these packages(glibc*.rpm..) from redhat to rpm packages that can be used on debian.Is there such tools exist on debian? 2. On Debian,after I install rpm,rpm DB and deb DB exist,Can I make some mapping bettwen betwwen rpm DB and deb DB? when I run rpm command,the OS will invoke debian DB.for example: # rpm -qv gcc package gcc is not installed #dpkg -l |grep gcc ii gcc-3.03.0.4-7The GNU C compiler. # this means gcc*rpm isn't installed but gcc*deb is installed on debian. after I make this mapping,I can use rpm to access deb DB. # rpm -qv gcc gcc-3.0 # if this way is feasible,How to do it? I am a new debian user,not too familiar with this OS, If above ways are impossible,is thers other ways to attain my purpose? Thanks! Rick --http://www.eyou.com --Îȶ¨¿É¿¿µÄµç×ÓÐÅÏä ÓïÒôÓʼþ Òƶ¯ÊéÇ© ÈÕÀú·þÎñ ÍøÂç´æ´¢...ÒÚÓÊδ¾¡ --http://vip.eyou.com --¿ì¿ìµÇ¼ÒÚÓÊVIPÐÅÏä ×¢²áÄúÖÐÒâµÄÓû§Ãû -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can rpm packages from other linux distribution be used on Debian?
On (12/05/04 17:40), Rick wrote: Hello People: Our product is base on redhat,I will porting it to Debian,but in this system,many procedure depend redhat rpms,for example: glibc-2.3.2-11.9.i386.rpm, perl-5.8.0-88.i386.rpm,etc.. At the start,I wanted to try install these rpm packages(from redhat) On debian,but I found that thers is a lot work to do,some rpm packages even can't be installed on it.(perhaps these rpms packages from redhat can't be used on debian at all).I think 2 ways to settle this problem,But I am not sure these ways is doable,and I wish to get some advices about it.these problem are: 1. Use a certain tool to translate these packages(glibc*.rpm..) from redhat to rpm packages that can be used on debian.Is there such tools exist on debian? Check out alien, a package specifically to convert rpms and you may want to look at: http://www.debian.org/doc/manuals/distribute-deb/distribute-deb.html 2. On Debian,after I install rpm,rpm DB and deb DB exist,Can I make some mapping bettwen betwwen rpm DB and deb DB? when I run rpm command,the OS will invoke debian DB.for example: # rpm -qv gcc package gcc is not installed #dpkg -l |grep gcc ii gcc-3.03.0.4-7The GNU C compiler. # this means gcc*rpm isn't installed but gcc*deb is installed on debian. after I make this mapping,I can use rpm to access deb DB. # rpm -qv gcc gcc-3.0 # if this way is feasible,How to do it? I am a new debian user,not too familiar with this OS, If above ways are impossible,is thers other ways to attain my purpose? Thanks! Rick -- http://www.clivemenzies.co.uk strategies for business -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can rpm packages from other linux distribution be used on Debian?
On Wed, May 12, 2004 at 05:40:51PM +0800, Rick wrote: Our product is base on redhat,I will porting it to Debian,but in this system,many procedure depend redhat rpms,for example: glibc-2.3.2-11.9.i386.rpm, perl-5.8.0-88.i386.rpm,etc.. At the start,I wanted to try install these rpm packages(from redhat) Once you have done that, the system is no longer really Debian, so I don't see the point. Figure out what Debian packages it depends on instead. On debian,but I found that thers is a lot work to do,some rpm packages even can't be installed on it.(perhaps these rpms packages from redhat can't be used on debian at all). In general they shouldn't be. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Can rpm packages from other linux distribution be used on Debian?
Thank you for your help,I should check the alien manual in detail first.
Re: Re: Can rpm packages from other linux distribution be used on Debian?
Our product is base on redhat,I will porting it to Debian,but in this system,many procedure depend redhat rpms,for example: glibc-2.3.2-11.9.i386.rpm, perl-5.8.0-88.i386.rpm,etc.. At the start,I wanted to try install these rpm packages(from redhat) Once you have done that, the system is no longer really Debian, so I don't see the point. Figure out what Debian packages it depends on instead. Yes,I think so.but our procedure depend rpm format,and I found that it can't find files it need in deb DB,I had been tried to install it on debian, #rpm -ivh myproduct-xxx-xx.rpm the program will prompt: myproduct need perl 5.6, and the bash must be installed In fact,the 2 debian packages has been installed,I think rpm command will read info from only rpm DB on debian.(If make myproduct-xxx-xx.rpm to deb format,I think more codes need be fixed,this proccess is complex,but I hadn't tried this way yet,I should try it tomorrow.) On debian,but I found that thers is a lot work to do,some rpm packages even can't be installed on it.(perhaps these rpms packages from redhat can't be used on debian at all). In general they shouldn't be. Thank you! Rick
about using rpm command error in debian
hi I am a debian new user.I had set up Debian env,I will use rpm on it,but when I run rpm -qa,the following error showed: --- # rpm -qa error: cannot open Packages index using db3 - No such file or directory (2) # --- My Debian kernel is 2.4.18-bf2.4. Can you tell me How to handle it? Thanks Rick _ MSN Explorer: http://explorer.msn.com/lccn/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: about using rpm command error in debian
On Monday 10 May 2004 10:01, li Rick wrote: I am a debian new user.I had set up Debian env,I will use rpm on it,but when I run rpm -qa,the following error showed: If you're a new user to Debian you might like to use apt instead of RPM. In my opinion it is a lot more flexible and is designed for Debian so should work out of the box. Both dselect and aptitude provide a frontend that you can use to choose and install packages. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: about using rpm command error in debian
On Mon, May 10, 2004 at 05:01:03PM +0800, li Rick wrote: I am a debian new user.I had set up Debian env,I will use rpm on it,but when I run rpm -qa,the following error showed: --- # rpm -qa error: cannot open Packages index using db3 - No such file or directory (2) # Debian doesn't use RPM. The sort of thing you're trying to do Just Won't Work without a lot of manual hacking; if you're going to do that then you might as well run an RPMish distribution to start with. Use the Debian package management tools instead. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Paquetes RPM.
Buenos días, Sigo haciendo preguntas - más que nada para no ... - estoy intentando instalar el JFFNMS ( Just For Fun Networks ) y uno de los requisitos es el Mysql-server, hasta aquí bien, me he conectado a la página de mysql.com y estoy bajandome el paquete MySQL-server-4.0.18-0.i386.rpm vuelvo a decir que de Linux se muy poco así que quizás la pregunta será muy básica, creo que los paquetes .rpm son de Red Hat ¿no? como puedo compilar este paquete en un Debian. Saludos y gracias por todo, Pd.: Espero algún dia poder responder a alguna pregunta. Gustau Espinosa de los Monteros attachment: winmail.dat
Re: Paquetes RPM.
Gustau Espinosa de los Monteros Miguel escribió: Buenos días, Sigo haciendo preguntas - más que nada para no ... - estoy intentando instalar el JFFNMS ( Just For Fun Networks ) y uno de los requisitos es el Mysql-server, hasta aquí bien, me he conectado a la página de mysql.com y estoy bajandome el paquete MySQL-server-4.0.18-0.i386.rpm vuelvo a decir que de Linux se muy poco así que quizás la pregunta será muy básica, creo que los paquetes .rpm son de Red Hat ¿no? como puedo compilar este paquete en un Debian. En Debian tenemos apt-get que es una maravilla. Como root pon apt-get update para actualizar la lista del repositorio Y luego apt-get install (nombre del paquete que quieras instalar). Y él solito lo hace. Si quieres buscar algún paquete de los disponibles (más de 10.000 en Sid, me parece) pon apt-cache search (texto que quieras buscar) Espero que te sirva Saludos y gracias por todo, Pd.: Espero algún dia poder responder a alguna pregunta. Gustau Espinosa de los Monteros
Re: Paquetes RPM.
El Jueves, 26 de Febrero de 2004 09:45, Gustau Espinosa de los Monteros Miguel escribió: Buenos días, Sigo haciendo preguntas - más que nada para no ... - estoy intentando instalar el JFFNMS ( Just For Fun Networks ) y uno de los requisitos es el Mysql-server, hasta aquí bien, me he conectado a la página de mysql.com y estoy bajandome el paquete MySQL-server-4.0.18-0.i386.rpm vuelvo a decir que de Linux se muy poco así que quizás la pregunta será muy básica, creo que los paquetes .rpm son de Red Hat ¿no? como puedo compilar este paquete en un Debian. Este paquete no lo puedes compilar ya que ya lo está ;-), existe una utilidad, alien, que intenta regormatear paquetes rpm para convertirlos en paquetes deb pero no tiene por que funcionar con todos. Yo de ti bajaría el código fuente y compilaría ( http://www.mysql.com/get/Downloads/MySQL-4.0/ mysql-4.0.18.tar.gz/from/http://mirrors.sunsite.dk/mysql/ ) Tambien tienes la opción de apt apt-get install mysql-server
Re: Paquetes RPM.
On Thu, Feb 26, 2004 at 09:45:11AM +0100, Gustau Espinosa de los Monteros Miguel wrote: Buenos días, Sigo haciendo preguntas - más que nada para no ... - estoy intentando instalar el JFFNMS ( Just For Fun Networks ) y uno de los requisitos es el Mysql-server, hasta aquí bien, me he conectado a la página de mysql.com y estoy bajandome el paquete MySQL-server-4.0.18-0.i386.rpm vuelvo a decir que de Linux se muy poco así que quizás la pregunta será muy básica, creo que los paquetes .rpm son de Red Hat ¿no? como puedo compilar este paquete en un Debian. Lo que te conviene hacer, es instalar el paquete que ya viene para debian: apt-get install mysql-server -- Ricardo A.Frydman Analista de Sistemas de Computación http://www.eureka-linux.com.ar pgp9auyckXR4N.pgp Description: PGP signature
Re: Alien from Red Hat rpm or Fedora Core rpm?
* Adam Funk ([EMAIL PROTECTED]) [040217 00:48]: On Monday 16 February 2004 21:30, Vineet Kumar wrote: (1) So it doesn't matter what distribution your rpm was targetted for; in most cases, it's not debian, and installing it on your debian system will most likely result in a system which is in violation of debian policy. This doesn't necessarily mean anything bad; just that your system isn't really a clean debian system anymore, and that should be taken into account when considering any bugs you may experience. (2) I think a better answer to software not available from debian directly is usually to compile and install in /usr/local, rather than resorting to trying to install foreign packages. Luckily, the dependencies I was a little confused by this: could you tell me if I'm interpreting it correctly? I think that (1) produces an unclean system because non-Debian stuff is installed in /usr/bin, /usr/man, /usr/lib, etc., whereas (2) is better because the stuff that is not produced from Debian packages is in /usr/local/* -- is that right? Yup. I suppose it's all a matter of opinion, but yes, it sounds like you are interpreting what I said correctly. good times, Vineet -- http://www.doorstop.net/ -- --Nick Moffitt A: No. Q: Should I include quotations after my reply? signature.asc Description: Digital signature
