On Sat, May 20, 2000 at 06:29:01PM -0500, w trillich wrote:
apropos? okay, i'll try that...
man -k is easier to type. :P
CONCLUSION:
there are #NO# pointers from a standard cd-install of slink,
Of course not. Correct me if I'm wrong but apt didn't really come into
its own
Previously Joey Hess wrote:
http://www.debian.org/Lists-Archives/debian-dpkg-0004/msg2.html
Okay, but that issue assumes that a package leaves a bomb in its
prerm. There is no way to protect yourself from such trojan packages
anyway, wether you use rpm or dpkg.
Wichert.
--
Wichert Akkerman wrote:
Previously Joey Hess wrote:
http://www.debian.org/Lists-Archives/debian-dpkg-0004/msg2.html
Okay, but that issue assumes that a package leaves a bomb in its
prerm. There is no way to protect yourself from such trojan packages
anyway, wether you use rpm or dpkg.
On Sun, May 21, 2000 at 07:46:47PM -0800, Ethan Benson wrote:
i think dlocate really takes care of the problem nicely, for things
like status and file lists dlocate is quite fast. its unfortunate that
it was removed from potato for a *ONE LINE BUG* with a fix in the
bts... why oh why could
Thus spake w trillich on Sun, May 21, 2000 at 01:49:35PM CDT
which is why it should not surprise any gurus on this list that
newbies upgrading from slink know nothing about APT or its magic.
they don't rtfm because they don't know about it.
NEWBIES: check out 'apt-get'! it's better than
Previously Joey Hess wrote:
When we were talking about this at the office, we did come up with one
situaton where the rpm ordering actually let you correct problems in
a previous package in a way dpkg's ordering did not. However, I figured
out a workaround we could use if we ever ran into that
Ethan Benson [EMAIL PROTECTED] writes:
On Sat, May 20, 2000 at 07:07:00PM +0200, Wichert Akkerman wrote:
That is a result of the fact that rpm uses a binary database for its
data, while dpkg uses a large number of text-files instead. The
advantage of that is that it is robust (if a single
I never took the time to read all of this mail (had to do with the mail
you send right afterwards to me only, I though it would go in the same
direction), but I agree with the problem. I've already mailed the package
maintainers of apt-get with a possible solution: point out to apt-get
before
Wichert Akkerman wrote:
Can you tell me which problem that was?
http://www.debian.org/Lists-Archives/debian-dpkg-0004/msg2.html
--
see shy jo
On Sat, May 20, 2000 at 07:37:59PM -0800, Ethan Benson wrote:
Apt uses a mixed approach: it uses the same textfiles as dpkg but
uses a binary cache to also get the advantages of a binary database.
it does? where?
See /var/cache/apt/*.bin files.
An example why is that good is the speed of
That's why I said to point to it during installation!
Ron Rademaker
On Sat, 20 May 2000, w trillich wrote:
seems like an uphill battle, eh?
Ron Rademaker wrote:
Try: pt-get install pine
It'll give youenough information to get a bit further
Ron Rademaker
PS. Damn when
On Sat, May 20, 2000 at 06:29:01PM -0500, w trillich wrote:
apropos? okay, i'll try that...
man -k is easier to type. :P
CONCLUSION:
there are #NO# pointers from a standard cd-install of slink,
Of course not. Correct me if I'm wrong but apt didn't really come into
its own
Steve Lamb wrote:
On Sat, May 20, 2000 at 06:29:01PM -0500, w trillich wrote:
there are #NO# pointers from a standard cd-install of slink,
Of course not. Correct me if I'm wrong but apt didn't really come into
its own as the standard package tool until potato.
you're probably right.
Wichert Akkerman wrote:
I wouldn't call it nonsensical, but the way dpkg does it is definitely
more robust. I need to take another close look at how rpm and dpkg
differ in this respect anyway, so if people are interested in the little
details I might be willing to write a little comparison
On Sat, May 20, 2000 at 07:37:39PM -0800, Ethan Benson wrote:
On Sat, May 20, 2000 at 07:07:00PM +0200, Wichert Akkerman wrote:
Previously Keith G. Murphy wrote:
I must say, my subjective experience has been that rpm's are much
faster to install something. Of course, it's also faster to
On Sun, May 21, 2000 at 11:38:18AM +0200, Josip Rodin wrote:
On Sat, May 20, 2000 at 07:37:59PM -0800, Ethan Benson wrote:
Apt uses a mixed approach: it uses the same textfiles as dpkg but
uses a binary cache to also get the advantages of a binary database.
it does? where?
See
On Mon, May 22, 2000 at 11:22:47AM +1000, Craig Sanders wrote:
agreed, the plain text db is the right way to do it.
OTOH, it would be nice if dpkg did what apt does and uses a binary db
cache to speed up operations...updating both binary and text versions
as changes are made.
the text
Because Univ of Washington doesn't allow modified tarballs to be
distributed, and you have to modify the tarball's paths to be Debian
compliant.
It's not too hard to find pine*.deb. Use Fast FTP Search.
Pine _is_ semi-officially available as a (contrib/non-free) part of debian.
The package
Previously Keith G. Murphy wrote:
I must say, my subjective experience has been that rpm's are much faster
to install something. Of course, it's also faster to throw my clothes
on the floor, rather than put them in the hamper...
That is a result of the fact that rpm uses a binary database for
seems like an uphill battle, eh?
Ron Rademaker wrote:
Try: pt-get install pine
It'll give youenough information to get a bit further
Ron Rademaker
PS. Damn when is someone going to read apt-ge's FM!!, perhaps we'll just
have to put a few pages with apt-get info during install on
On Sat, May 20, 2000 at 07:07:00PM +0200, Wichert Akkerman wrote:
Previously Keith G. Murphy wrote:
I must say, my subjective experience has been that rpm's are much faster
to install something. Of course, it's also faster to throw my clothes
on the floor, rather than put them in the
I went through this with Terry Gray (Pine Development Team) and Santiago
Vila (Debian maintainer of the Pine source) about the time Pine 4.20
was coming out...
On Thu, 18 May 2000, Will Lowe wrote:
Can I ask why debian doesn't include pine? Just curious. I know Debian
The license for pine
So, it is not so much that Debian doesn't have permission to distribute
a modified binary package, it is that doing so would open up a whole
can'o'worms w.r.t. redistribution... so why go there and possibly cause
problems for Debian's distributors, eh.
That's exactly why it doesn't pass the
On Fri, May 19, 2000 at 02:52:16AM -0400, Will Lowe wrote:
So, it is not so much that Debian doesn't have permission to distribute
a modified binary package, it is that doing so would open up a whole
can'o'worms w.r.t. redistribution... so why go there and possibly cause
problems for
Michel Verdier wrote:
[cut]
Everybody knows that .deb are usually the last to be released to increase
stability for .deb packages. When security is an issue .rpm and .deb are
both tested and it would be great to have statistics to know which is the
quicker to be installed and used.
I must
It's not too hard to find pine*.deb. Use Fast FTP Search.
At 09:54 AM 5/19/00 +0800, Sanjeev \Ghane\ Gupta wrote:
Because Univ of Washington doesn't allow modified tarballs to be
distributed, and you have to modify the tarball's paths to be Debian
compliant.
Try: pt-get install pine
It'll give youenough information to get a bit further
Ron Rademaker
PS. Damn when is someone going to read apt-ge's FM!!, perhaps we'll just
have to put a few pages with apt-get info during install on the users
screen, the amount of question that has to do with it
Jeremy == Jeremy Hansen [EMAIL PROTECTED] writes:
Jeremy Autoinstall (Red Hat's kickstart)
Jeremy This is also something fairly important. We need this as we do
a
Jeremy lot of mass installs.
The best way to do that that I've found so far is to set up a box
with two
Chris == Chris Wagner [EMAIL PROTECTED] writes:
Chris For mass installs, just make a standard issue CD, boot from that CD,
and
Chris copy over the OS. Or you could even make a disk image and dd it
onto the
Chris hard drive. That assumes you have the same hard drive in all the
Steve == Steve Morocho [EMAIL PROTECTED] writes:
Steve I agree, rpm is not a piece of crap. deb packages are a
Steve lot harder to create for the novice users. There is not
Steve much documentation to help in this area either. Also, when
Steve updates are released .debs are
[...]
KMH The best way to do that that I've found so far is to set up
KMH a box with two removable hard drive racks, install and
KMH _configure_ everything on one drive, then use `cfdisk',
KMH `mkswap', and `mke2fs' to partition and format the second
KMH drive.
[...]
I do a
Hi..
I worked on debian (first private than at work) and redhat (and SuSe, only
for money :), and my personal opinion ist, that debian Packages are much
more smoother to handle than rpm's.
As long as you don't build your own Packages. Mostly i can use make-kpkg. :)
to make my kernel-images. I
On Thu, May 18, 2000 at 10:42:17AM +0200, Andreas Rabus wrote:
- Hard to build. There is a large doc about this task , but it still
takes a long time to learn.
so does system administration for *nix. as it should be, learning
takes time and is something no one should ever shy away from.
The monkeys ar not very polite, but ... :)
My experience is not that bad, but some of the rpm i installed were a real
mess, too.
But i liked to see some companies to release there software in various
flavours of package formats.
ar
PS: you never learn NT. If you learnd on Version, you
On Thu, May 18, 2000 at 11:19:31AM +0200, Andreas Rabus wrote:
The monkeys ar not very polite, but ... :)
considering the quality of most .rpms i found in places like /contrib
i don't think that is at all unfair. ;-)
`monkeys' is about as polically correct as your going to get from me,
Previously Chip Salzenberg wrote:
Actually, from what I've been told, rpm has at least one serious
technical flaw: The order of execution for pre-install and
post-install scripts is nonsensical for upgrades.
I wouldn't call it nonsensical, but the way dpkg does it is definitely
more robust. I
Steve Morocho [EMAIL PROTECTED] a écrit :
| I agree, rpm is not a piece of crap. deb packages are a lot harder to
| create for the novice users. There is not much documentation to help in
| this area either. Also, when updates are released .debs are usually the
| last to be released (because
Thursday, May 18, 2000, 5:16:08 AM, Michel wrote:
.deb is already a standard package system in the industry. And again it
would be nice to have statistics to confirm this purely subjective
statement :)
Purely anecdotal, but Earthlink uses dpkg and deb as their internal format
for binary
On Thu, May 18, 2000 at 02:16:08PM +0200, Michel Verdier wrote:
| deb packages are a lot harder to create for the novice users. There is
| not much documentation to help in this area either.
There is perhaps not much documentation but :
# ls /usr/man/man1/dh*|wc -l
30
You people
On Thu, 18 May 2000, Steve Lamb wrote:
Purely anecdotal, but Earthlink uses dpkg and deb as their internal format
for binary distribution for servers. Not much in the way of Debian machines,
just the packaging format. :)
Apple's DarwinOS also uses the dpkg tools. (So maybe Apple OS X
Most of the answers I've been getting on this subject seem like total
hacks, which may work but really are tricks to doing this. I was really
looking for something within debian that's built to do kickstart type
installations.
Although what you suggest may work, it leave little flexibility
On Thu, 18 May 2000, Wichert Akkerman wrote:
Previously Chip Salzenberg wrote:
Actually, from what I've been told, rpm has at least one serious
technical flaw: The order of execution for pre-install and
post-install scripts is nonsensical for upgrades.
I wouldn't call it nonsensical,
Are you aware of this?
http://www.informatik.uni-koeln.de/fai/
-- Mike
On 2000-05-18 at 13:55 -0400, Jeremy Hansen wrote:
It seems a lot of Debian users are developers and in this case I'm sure
Debian is perfect, but Red Hat's kickstart allows me to see my wife at
night (not
I would agree most of the proposed solutions are quick hacks.
The fact is, we won't be natively supporting bulk installation until
Woody. And even that is in question. As I understand it, the
proposed Woody install system is debconf based; moreover, debconf can
have different backends for
Agreed that this seems technically sound, but it would be really nice to
have this Real Soon Now. I think it might be reasonably possible to
backport this from Woody into Potato fairly soon after the release of
Potato. The fact is that an automatic installation system will be really
hard to test
On Thu, May 18, 2000 at 01:55:37PM -0400, Jeremy Hansen wrote:
Most of the answers I've been getting on this subject seem like
total hacks, which may work but really are tricks to doing this. I
was really looking for something within debian that's built to do
kickstart type installations.
Ethan Benson wrote:
On Thu, May 18, 2000 at 10:42:17AM +0200, Andreas Rabus wrote:
I've only been using Linux since Feb. , so at the local LUG I usually just
listen to the discussions and take in as much as I can. The people there (LUG)
are about 80% RedHat users with the rest divided btw SuSe
On Thu, May 18, 2000 at 01:24:26PM -0700, Stephen A. Witt wrote:
A lot of what makes Debian cool is appreciated only after some time
with it.
also, a lot of what debian does is only appreciated after you've had the
misfortune of working with some other distros for a while...then you
really
At 09:55 PM 5/17/00 -0700, Karl M. Hegbloom wrote:
copy everything from the master drive to the copy, then run the
appropriate Lilo command to make that copy bootable. You can then
mount it in another machine and it's ready to go. You have to filter
some things out when you copy. See below.
On Thu, May 18, 2000 at 05:54:54PM -0400, Mike Bilow wrote:
Are you aware of this?
http://www.informatik.uni-koeln.de/fai/
Another tool to do this is Replicator. Sorry, but I don't a link nearby.
Search for it in google.
On 2000-05-18 at 13:55 -0400, Jeremy Hansen wrote:
It seems
If kickstart is a red hat package, you can install it on debian using alien.
Then you can use red hat's kickstart to install debian. :)
At 01:55 PM 5/18/00 -0400, Jeremy Hansen wrote:
Most of the answers I've been getting on this subject seem like total
hacks, which may work but really are tricks
Hmm, I don't agree here. Kickstart is a way of automating the tasks
already involved with a manual install. It does what it's supposed to do
quite well and actually with the flexibility available, I rarely encounter
a situation that requires more custom things. Hacks can be included in
Can I ask why debian doesn't include pine? Just curious. I know Debian
has a very strict rule base on the packages it includes but every distro I
have even installed always included pine and I was just wondering the
reason behind not doing that with Debian.
-jeremy
On Thu, May 18, 2000 at
Well it's funny you brought that up because I was considering just making
one huge rpm of debian and then using kickstart. Kickstart is a part of
Red Hat's install, Anaconda, not really an rpm but I get your point.
-jeremy
If kickstart is a red hat package, you can install it on debian using
Can I ask why debian doesn't include pine? Just curious. I know Debian
The license for pine doesn't allow you to redistribute modified binaries
(e.g., fix a bug in the source, compile it, and redistribute the
executable you get from this). Therefore, it can't be included as part of
Debian --
Message -
From: Jeremy Hansen [EMAIL PROTECTED]
To: Craig Sanders [EMAIL PROTECTED]
Cc: Stephen A. Witt [EMAIL PROTECTED]; Debian User
debian-user@lists.debian.org; debian-isp@lists.debian.org;
debian-dpkg@lists.debian.org
Sent: Friday, May 19, 2000 9:29 AM
Subject: Re: Debian vs Red Hat??? I need
[Trimmed extraneous debian-isp and debian-dpkg cc:'s, hope that's enough]
On Thu, 18 May 2000, Chris Wagner wrote:
At 09:55 PM 5/17/00 -0700, Karl M. Hegbloom wrote:
copy everything from the master drive to the copy, then run the
appropriate Lilo command to make that copy bootable. You can
On Thu, May 18, 2000 at 09:29:03PM -0400, Jeremy Hansen wrote:
Can I ask why debian doesn't include pine? Just curious.
because it's a violation of pine's license to distribute modified
binaries.
pine is non-free.
debian distributes a pine-src package (in non-free) which contains the
pine
Craig == Craig Sanders [EMAIL PROTECTED] writes:
For example, I have 20 machines at a co location I need to go install.
Right now with Red Hat I can take my laptop, slap a floppy in each
machine, turn 'em on, 5 minutes later I have 20 fully configured
machines ready to rock.
On Tue, May 16, 2000 at 06:48:02PM -0400, Jeremy Hansen wrote:
I'm a long time Red Hat user. Basically the company I'm working for is
currently using Red Hat but for some reason they're considering switching
to Debian. I personally don't have any experience with Debian abd
honestly I'm
On Tue, May 16, 2000 at 08:44:38PM -0700, David Lynn wrote:
I agree - dpkg and apt are great compared to rpm's. However, that's all
assuming that there are debian packages out there that are up to date
(which they're generally not). But this seems to be the only major
drawback I've found to
On Tue, May 16, 2000 at 10:43:20PM -0400, Chris Wagner wrote:
At 07:29 PM 5/16/00 -0400, Jeremy Hansen wrote:
Autoinstall (Red Hat's kickstart)
This is also something fairly important. We need this as we do a
lot of mass installs.
For mass installs, just make a standard issue CD, boot
On Tue, May 16, 2000 at 08:44:18PM -0700, David Lynn wrote:
I agree - dpkg and apt are great compared to rpm's. However, that's
all assuming that there are debian packages out there that are up to
date (which they're generally not). But this seems to be the only
major drawback I've found to
On Tue, May 16, 2000 at 11:24:50PM -0700, Steve Lamb wrote:
On Tue, May 16, 2000 at 08:44:38PM -0700, David Lynn wrote:
I agree - dpkg and apt are great compared to rpm's. However, that's all
assuming that there are debian packages out there that are up to date
(which they're generally
Bruce Sass [EMAIL PROTECTED] a écrit :
| On Wed, 17 May 2000, Matthew Dalton wrote:
| I beleive it is possible to install a Debian system, configure/customise
| it, and then repackage the deb packages using the customised files on
| the system instead of the original default ones, using some
On Wed, May 17, 2000 at 05:28:54PM +1000, Craig Sanders wrote:
On Tue, May 16, 2000 at 10:43:20PM -0400, Chris Wagner wrote:
At 07:29 PM 5/16/00 -0400, Jeremy Hansen wrote:
Autoinstall (Red Hat's kickstart)
This is also something fairly important. We need this as we do a
lot of mass
Previously Chris Wagner wrote:
RPM is a piece of crap compared to dpkg, and now we have apt (advanced
package tool).
Can we please not be so negative about rpm? I'll agree that dpkg is
better (and of course I'm completely not biased here :), but rpm
is not a piece of crap.
Wichert.
--
On Wed, May 17, 2000 at 08:44:15AM +0200, Johann Spies wrote:
I don't find this to be true. If you need the latest bleeding edge
program, go with the unstable tree which has historically proven to be more
stable than Red Hat Releases.
(or python-wxwin in Debian language) and while
On Wed, May 17, 2000 at 02:55:33PM +0200, Wichert Akkerman wrote:
Can we please not be so negative about rpm? I'll agree that dpkg is
better (and of course I'm completely not biased here :), but rpm
is not a piece of crap.
OK, in the light of trying to say something positive about rpm
On Wed, May 17, 2000 at 06:17:14AM -0700, Steve Lamb wrote:
On Wed, May 17, 2000 at 02:55:33PM +0200, Wichert Akkerman wrote:
Can we please not be so negative about rpm? I'll agree that dpkg is
better (and of course I'm completely not biased here :), but rpm
is not a piece of crap.
On Wed, May 17, 2000 at 05:35:20AM -0800, Ethan Benson wrote:
that would make a nice .sig if it weren't so long ;-)
What? It is under 4 lines long. ;)
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the
I agree, rpm is not a piece of crap. deb packages are a lot harder to create
for the novice users. There is not much documentation to help in this area
either. Also, when updates are released .debs are usually the last to be
released (because someone usually
has to hack an .rpm or something
I have to disagree there. I've found Debian packs to be extremely up to
date, atleast on the security end. And even on routine maintanance, the lag
is not that bad.
At 08:44 PM 5/16/00 -0700, David Lynn wrote:
I agree - dpkg and apt are great compared to rpm's. However, that's all
assuming
Sorry, but I was so underwhelmed by rpm's capabilities and my reaction was
so one sidedly negative that I can't describe it any other way. It is what
I typed.
At 02:55 PM 5/17/00 +0200, Wichert Akkerman wrote:
Previously Chris Wagner wrote:
RPM is a piece of crap compared to dpkg, and now we
Folks,
I have used dpkg, and been forced to use rpm, and rpm is just as good, more
or less.
The problem is that there is nothing equivalent to dselect or apt in RedHat.
I rarely call dpkg directly, unless libc6 is stuck again ;-), but the
nearest that RedHat has to a mid-level tool is GnoRPM,
According to Sanjeev Ghane Gupta:
I have used dpkg, and been forced to use rpm, and rpm is just as
good, more or less.
Actually, from what I've been told, rpm has at least one serious
technical flaw: The order of execution for pre-install and
post-install scripts is nonsensical for upgrades. I
I'm a long time Red Hat user. Basically the company I'm working for is
currently using Red Hat but for some reason they're considering switching
to Debian. I personally don't have any experience with Debian abd
honestly I'm open to anything but I was hoping for some positive feedback
from
I'm a long time Red Hat user. Basically the company I'm working for is
currently using Red Hat but for some reason they're considering switching
to Debian. I personally don't have any experience with Debian abd
honestly I'm open to anything but I was hoping for some positive feedback
from
Jeremy Hansen [EMAIL PROTECTED] writes:
JH Dpkg vs RPM
JH Both managability and build packages. I have heard a lot
JH of good things about dpkg.
My experience has been that it can be extremely hard to upgrade a
system from one RH release to another, and that RH is very bad about
David Z Maze wrote:
JH Autoinstall (Red Hat's kickstart)
JH This is also something fairly important. We need this as we do a
JH lot of mass installs.
This isn't quite there. IANADD, but my guess is that this
functionality will probably appear (via APT and debconf) in a few
On Tue, May 16, 2000 at 07:55:16PM -0400, David Z Maze wrote:
Debian seems to be fairly tweak-friendly; dpkg makes an effort to not
overwrite users' configuration files without advance notice. Building
Debian packages takes a little work, but there are semiautomated tools
that help a lot.
Dpkg beats RPM hands down for anyone who has to actualy administer a
number of boxes and wants everything as automatic as possible (for
upgrades).
As far as being able to customize the distro - go all out. You can of
course edit config files at the vi level ;) There are also tools to
take the
On Wed, 17 May 2000, Matthew Dalton wrote:
I beleive it is possible to install a Debian system, configure/customise
it, and then repackage the deb packages using the customised files on
the system instead of the original default ones, using some provided
tools.
Can anyone confirm this? I
At 07:29 PM 5/16/00 -0400, Jeremy Hansen wrote:
I'm a long time Red Hat user. Basically the company I'm working for is
Sorry about that. :)
Dpkg vs RPM
RPM is a piece of crap compared to dpkg, and now we have apt (advanced
package tool). It's a handler for dpkg, but it's intelligent. The
I agree - dpkg and apt are great compared to rpm's. However, that's all
assuming that there are debian packages out there that are up to date
(which they're generally not). But this seems to be the only major
drawback I've found to Debian.
--d
85 matches
Mail list logo
