Re: [Cooker] rpms suck
[EMAIL PROTECTED] wrote: > rsync (at least with default block size) is ineffective for compression >> used in RPM. You gain nothing; actually you just incur more overhead due >> to rsync protocol. > > Not true, have you used Ron Stoddens rsyncpl script, > All I can say is that it is almost like magic watching > it update a 2 Meg RPM on 15 seconds on a 56K dialup link. > Hmm ... my impression was there was no speedup. I probably should test it once more. Where rsync really helps is updating of hdlists. But I assumed RPM is using different compression so it does not play nicely with rsync block checksums. -andrej
Re: [Cooker] rpms suck
Borsenkow Andrej wrote: > >>>automatically download files. >>> >>With rsync like functionality you would have do download signifcant >> > less > >>if you already have the old rpm >> >> > > rsync (at least with default block size) is ineffective for compression > used in RPM. You gain nothing; actually you just incur more overhead due > to rsync protocol. > > > -andrej > Not true, have you used Ron Stoddens rsyncpl script, All I can say is that it is almost like magic watching it update a 2 Meg RPM on 15 seconds on a 56K dialup link. -- John Allen email: [EMAIL PROTECTED] OpenSource Developer: www: http://udk.sf.net phone: intl+353-14937616 : intl+353-862315986
Re: [Cooker] rpms suck
Alexander Skwar wrote: > Am Don, 2001-10-04 um 21.07 schrieb 100441: > >>OK, so what we need is rsync like functionality in rpm, and a special >>rpm server. >> > > RPM can already by itself download files from http/ftp servers. So > what's a special server good for? And in combination with urpmi you can > automatically download files. > > Well rsync does binary patching, so a modified RPM that recognises that you have a cached previous release could manufacture a local copy of the new release by copying the old release to the new name, and binary patching it from the new one. Check out how rsync works on www.samba.org -- John Allen email: [EMAIL PROTECTED] OpenSource Developer: www: http://udk.sf.net phone: intl+353-14937616 : intl+353-862315986
Re: [Cooker] rpms suck
I don't like huge downloads, but I do like things to work . :) -jm On Thursday 04 October 2001 10:53 pm, you wrote: > On Thu, Oct 04, 2001 at 09:09:21PM -0500, Joe Menola wrote: > > Why can't rpm's just included ALL the required libs... if it's already on > > your system the installer simply skips it? > > Imagine including all the required libs for say mozilla: > > [breser@titanium breser]$ rpm -qR mozilla > indexhtml > /bin/sh > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > ld.so.1 > libc.so.6 > libdl.so.2 > libgkgfx.so > libjsj.so > libmozjs.so > libm.so.6 > libnspr4.so > libplc4.so > libplds4.so > libpthread.so.0 > libstdc++-libc6.2-2.so.3 > libxpcom.so > libcmt.so > libgdk-1.2.so.0 > libglib-1.2.so.0 > libgmodule-1.2.so.0 > libgtk-1.2.so.0 > libgtksuperwin.so > libgtkxtbin.so > libICE.so.6 > libjpeg.so.62 > libjsdom.so > liblcms.so.1 > libmng.so.1 > libpng.so.2 > libprotocol.so > libSM.so.6 > libX11.so.6 > libXext.so.6 > libXi.so.6 > libXt.so.6 > libz.so.1 > bash > libc.so.6(GLIBC_2.0) > libc.so.6(GLIBC_2.1) > libdl.so.2(GLIBC_2.0) > libdl.so.2(GLIBC_2.1) > libm.so.6(GLIBC_2.0) > libpthread.so.0(GLIBC_2.0) > libpthread.so.0(GLIBC_2.1) > rpmlib(CompressedFileNames) <= 3.0.4-1 > > If you did this I hope you like huge downloads. > > Also it would make it impossible to fit on 2 or 3 cds. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [Cooker] rpms suck
> > Am Don, 2001-10-04 um 21.07 schrieb 100441: > > OK, so what we need is rsync like functionality in rpm, and a special > > rpm server. > > RPM can already by itself download files from http/ftp servers. So > what's a special server good for? And in combination with urpmi you can > automatically download files. With rsync like functionality you would have do download signifcant less if you already have the old rpm > > Alexander Skwar > How to quote: http://learn.to/quote (german) http://quote.6x.to > (english) > Homepage: http://www.digitalprojects.com | http://www.iso-top.de >iso-top.de - Die g=FCnstige Art an Linux Distributionen zu kommen > Uptime: 1 day 0 hours 9 minutes >
RE: [Cooker] rpms suck
> > > > Am Don, 2001-10-04 um 21.07 schrieb 100441: > > > OK, so what we need is rsync like functionality in rpm, and a special > > > rpm server. > > > > RPM can already by itself download files from http/ftp servers. So > > what's a special server good for? And in combination with urpmi you can > > automatically download files. > > With rsync like functionality you would have do download signifcant less > if you already have the old rpm > rsync (at least with default block size) is ineffective for compression used in RPM. You gain nothing; actually you just incur more overhead due to rsync protocol. -andrej
Re: [Cooker] rpms suck
Am Don, 2001-10-04 um 21.07 schrieb 100441: > OK, so what we need is rsync like functionality in rpm, and a special > rpm server. RPM can already by itself download files from http/ftp servers. So what's a special server good for? And in combination with urpmi you can automatically download files. -- Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 1 day 0 hours 9 minutes
Re: [Cooker] rpms suck
On Thu, Oct 04, 2001 at 09:09:21PM -0500, Joe Menola wrote: > Why can't rpm's just included ALL the required libs... if it's already on > your system the installer simply skips it? Imagine including all the required libs for say mozilla: [breser@titanium breser]$ rpm -qR mozilla indexhtml /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 ld.so.1 libc.so.6 libdl.so.2 libgkgfx.so libjsj.so libmozjs.so libm.so.6 libnspr4.so libplc4.so libplds4.so libpthread.so.0 libstdc++-libc6.2-2.so.3 libxpcom.so libcmt.so libgdk-1.2.so.0 libglib-1.2.so.0 libgmodule-1.2.so.0 libgtk-1.2.so.0 libgtksuperwin.so libgtkxtbin.so libICE.so.6 libjpeg.so.62 libjsdom.so liblcms.so.1 libmng.so.1 libpng.so.2 libprotocol.so libSM.so.6 libX11.so.6 libXext.so.6 libXi.so.6 libXt.so.6 libz.so.1 bash libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libdl.so.2(GLIBC_2.0) libdl.so.2(GLIBC_2.1) libm.so.6(GLIBC_2.0) libpthread.so.0(GLIBC_2.0) libpthread.so.0(GLIBC_2.1) rpmlib(CompressedFileNames) <= 3.0.4-1 If you did this I hope you like huge downloads. Also it would make it impossible to fit on 2 or 3 cds. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "Before you set out for revenge dig two graves." - Chinese Saying
Re: [Cooker] rpms suck
Why can't rpm's just included ALL the required libs... if it's already on your system the installer simply skips it? -jm On Thursday 04 October 2001 08:55 pm, you wrote: > Why aren't they better? Exactly *what* is so bad about RPM and DEB? > at least with rpms/rpm programs > 1 No easy way to dump your install cds in a folder and > quickly have deps > auto-resolved > 2 How does one recover from a burnt rpm database and have the info > acurate? > 3 dep trees get way too large. i propose ap.rpm, aplib.rpm, > apclient.rpm, apserver.rpm, apextras.rpm > so you don't land up installing glibc*.rpm just to get say a DVD player > running (and if your ap deps on someone elses > ap then have a copy on your site!) _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: [Cooker] rpms suck
Why aren't they better? Exactly *what* is so bad about RPM and DEB? at least with rpms/rpm programs 1 No easy way to dump your install cds in a folder and quickly have deps auto-resolved 2 How does one recover from a burnt rpm database and have the info acurate? 3 dep trees get way too large. i propose ap.rpm, aplib.rpm, apclient.rpm, apserver.rpm, apextras.rpm so you don't land up installing glibc*.rpm just to get say a DVD player running (and if your ap deps on someone elses ap then have a copy on your site!) -- Robert LaurenceMartin
Re: [Cooker] rpms suck
> > I suddenly contemplate a rpm system modified for a 'binary-diff' that > could have something like urpmi only fetch parts of the file. like > upgrading kernel source could be just one meg d/l, or any executibleish > app or whatever. freaky. i am sooo dilerious. contemplating > yogurt. > OK, so what we need is rsync like functionality in rpm, and a special rpm server. Jeez sounds like something I'd love to do. -- John Allen email: [EMAIL PROTECTED] OpenSource Developer: www: http://udk.sf.net phone: intl+353-14937616 : intl+353-862315986
Re: [Cooker] rpms suck
torsdagen den 4 oktober 2001 18.57 skrev George Mitchell: [snip] Ya'll should try LFS if RPM based stuff is not for you: www.linuxfromscratch.org. Good luck ;) -- Oden Eriksson, Jokkmokk, Sweden LM8.1, 2.4.10-1mdksmp, @ 16:37
Re: [Cooker] rpms suck
Well I have to agree on this one to a large extent. RPMs can be a real pain. However, once you get the hang of them, they are easier than installing from source. I seldom have problems with RPMs 'not installing right'. As far as conflicts go, the key is in understanding the output. There are a number of problems that can cause a conflict and the output of the rpm command can be very cryptic at times. Unsatisfied dependencies are often expressed in terms of a particular missing file rather than a missing package. Then how does one go about finding out which package contains the needed file? I do it by searching for info on the web, but not all users are going to be that up to speed on web search techniques. At other times one encounters archane interdependencies. For example, an essential component gets broken off from KDE. Now KDE suddenly needs that component in order to be upgraded. When you go to install that component, you of course end up with a conflict because it is already part of the current KDE. The solution of course is 'rpm -U '. But this software jigsaw puzzle can be extremely confusing to the novice. I think that the solution is not so much throwing RPM out, but rather enhancing RPM to deal with these circumstances. The packaging people need to think whenever they make a new package: 'How will this impact the user?' and 'How can we come up with a solution that will mitigate the potential impact on the user?' One thing I would like to suggest is the inclusion of a dynamic comment field to be included in the package. When an rpm fails for any reason, this comment field would appear in the output. Cooker testers would have some easy way to contribute to these comment fields. In most cases a few comments like: 'Try rpm -U ' or 'Be sure to install if it is not already installed' or 'Remove before installing' could go a long way toward solving these problems. Of course the long term solution would be a 'smarter' rpm that could ferret out an solve these problems on its own. George Mitchell [EMAIL PROTECTED] Mark D'voo wrote: > I would just like to state that mandrake is the best distribution of linux > and the best operating system known to man. It has a major problem. > RPMS!!! rpms suck. they never install right, everything conflicts, and i > have to install everything from source which isn't easy for a newbie. > Mandrake is still known as a redhat rip-off which is because it uses rpms. I > think mandrake needs to develop their own packaging system. Hopefully > mandrake would be able to come up with something better than rpms and debs > (since they aren't much better). If they could sucessfully do this, i > believe it would really help out mandrake. It would not longer be a redhat > rip-off instead other distros would use mandrakes installing system, and > they'd be mandrake rip-offs. > > mark
Re: [Cooker] rpms suck
On Thursday 04 October 2001 11:58, you wrote: > [Mandrake] has a major problem. RPMS!!! rpms suck. Actually, I think some of the dependencies suck. For example, some packages aren't very granular, so for example you might have to install mysql to make some tiny package happy because one of the interfaces it uses is mysql and there's no easy way to build it so that it will both do mysql and do without mysql. Another example, sometimes the dependencies are set to ``whatever I was compiled with'' - which is usually the latest and greatest - when something older would do fine. This results in having to upgrade half of your universe before everything is happy again. But count the packages in Mandrake 8.1 (2029 of them!) and be glad that someone had the time to package them at all, using _any_ packaging system! (-: > Mandrake is still known as a redhat rip-off which is because it uses rpms. No problem. I understand that 8.1's package manager also understands DEBs and other things. World domination is just to hand. (-:
Re: [Cooker] rpms suck
On Thursday 04 October 2001 05:58, you wrote: > I would just like to state that mandrake is the best distribution of linux > and the best operating system known to man. It has a major problem. > RPMS!!! rpms suck. they never install right, everything conflicts, and i > have to install everything from source which isn't easy for a newbie. > Mandrake is still known as a redhat rip-off which is because it uses rpms. > I think mandrake needs to develop their own packaging system. Hopefully If Mandrake were to develop yet another packaging system which were incompatible with RPM then one of the major strengths of the distro would die! One of the reasons that RPMs make mandrake great is that there are so many different programs available as RPM which work on almost all RPM based distros (excluding the RPMs which have distro specific dependencies of course).. I think it would kill Mandrake if they were to develop a new format! It would be much better to do what they are doing, improve RPM instead and evolve RPM while still maintaining a certain backwards compability.. > mandrake would be able to come up with something better than rpms and debs > (since they aren't much better). If they could sucessfully do this, i > believe it would really help out mandrake. It would not longer be a redhat > rip-off instead other distros would use mandrakes installing system, and > they'd be mandrake rip-offs. I really think that you have the wrong take on rip-offs .. this is Open Source, meaning that Red Hat made a great product which MandrakeSoft (which of course wasn't a reality then) saw and decided that they could make it even better.. so why reinvent the wheel again when RH has made quite a nice one for them to improve upon? This is one of the prime reasons for the speed with which Open Source development is taking place! So don't think of it as YAR (Yet-Another-Ripoff(tm)), instead think of it as an alternative to RH which still maintains the things from RH that made it great! -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GO d--@ s:+ a-- C++ $UL++ P+ L++ E- W+ N(+) o K? w !O M-- V? PS+ PE@ Y+ PGP t 5? X R+ tv+ b+ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK--
Re: [Cooker] rpms suck
So sprach »Mark D'voo« am 2001-10-03 um 22:58:18 -0500 : > Mandrake is still known as a redhat rip-off which is because it uses rpms. I Ah yeah, of course. SuSE, Conectiva, Kondara ... are also just RedHat rip-offs, right? But making a packaging system which is only used by Mandrake is a bad idea, I think. RPM isn't that bad - okay, I'd like it much better if Mandrake would use apt-get and .deb's, but RPM is the next best thing. > think mandrake needs to develop their own packaging system. Hopefully > mandrake would be able to come up with something better than rpms and debs > (since they aren't much better). If they could sucessfully do this, i Why aren't they better? Exactly *what* is so bad about RPM and DEB? Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 0 hours 27 minutes
Re: [Cooker] rpms suck
Mark D'voo wrote: > I would just like to state that mandrake is the best distribution of linux > and the best operating system known to man. It has a major problem. > RPMS!!! rpms suck. they never install right, everything conflicts, and i > have to install everything from source which isn't easy for a newbie. > Mandrake is still known as a redhat rip-off which is because it uses rpms. I > think mandrake needs to develop their own packaging system. Hopefully > mandrake would be able to come up with something better than rpms and debs > (since they aren't much better). If they could sucessfully do this, i > believe it would really help out mandrake. It would not longer be a redhat > rip-off instead other distros would use mandrakes installing system, and > they'd be mandrake rip-offs. > > mark Could you give us a list of problematic RPMS? It would be useful to resolve conflicts. Chris
