[Apt-Rpm] What is the best choice for RPM Update Tool

Tue Jan 8 23:41:40 PST 2008

Again I really appreciate your advices.
As I mentioned above, CentOS 4.5 is not really my target machine to run on
my project but MFP that requires run on RTOS like embedded Linux (for
example VxWorks). From a business POV as you recommended and from my study,
it is so attractive of the fact that yum has a huge support from rpm
community, maybe it it the strongest candidate for vendor business. But is
there any advance of apt to beat yum in using on embedded Linux as a rpm
package update tools such as: speed, smart dependency resolving, mini-ram
machine, easy to handle rpm packages, security.
Thank you for your attention,
Best regards,
Nguyen Anh Quan.
On Jan 9, 2008 4:07 AM, Axel Thimm <Axel.Thimm at atrpms.net> wrote:

> On Tue, Jan 08, 2008 at 02:31:01PM +0700, Quan phongvan wrote:
> > Thank you very much for your advices and comments, I appreciate your
> help.
> > I sorry for that my problem is not clear enough for you to give me more
> > details advice.
> > Here my issues:
> > My target machine is for MFP (Multi-fuction Peripherals) such as:
> all-in-one
> > standalone network printer.
> > The OS is used on MFP similar to RPM distro CentOS (that's reason why I
> test
> > all three of update tools on CentOS 4.5) - this OS is provider by
> windriver.
> > I've investigated three of update tools for the purpose: builing up an
> > robust RPM Package management system for MFP which run on Linux-RPM OS.
> > For Axel Thimm,
> > Your comment are great, I apprecite it. I've studied about these on yum
> when
> > "parallel" use all three: yum, smart. apt-rpm on CentOS.
> > If you don't mind, can you give me more comment about if I bring yum or
> > smart or apt-rpm into real serious project for update tool, which one
> would
> > have the most advantage above all, and why?.
>
> In your context the most important aspect is support by an upstream to
> your project. While it is not likely that you will create a situation
> in your repo that should confuse any of these tools, it is not
> impossible, and from a business POV you need to be able to react fast
> and have as little downtime as possible.
>
> This means yum - as yum is both supported by your CentOS upstream, as
> well as CentOS' own upstream, RHEL (yum is part of RHEL5). If you
> stick to yum then you only have to worry about issues that your own
> packages could create with yum (and you will be testing new packages
> before rolling them out, so you have your own repo under control),
> while all CentOS packages and bugs assorted with yum and these
> packages would affect the whole CentOS community and maybe even the
> RHEL5 community which mean much faster reaction times to any such
> defect in yum.
>
> E.g. I may be ranting about yum, but reality in vendor business means
> you need to choose this over the other solutions even if the other do
> have technical merits - as technical merits alone don't save a
> business' day.
>
> > Thank you for your attention,
> > Best regards,
> > Nguyen Anh Quan.
> >
> > On Jan 7, 2008 6:46 PM, Axel Thimm <Axel.Thimm at atrpms.net> wrote:
> >
> > > On Sun, Jan 06, 2008 at 04:00:14PM +0100, Sven Hoexter wrote:
> > > > On Sun, Jan 06, 2008 at 03:37:36PM +0200, Panu Matilainen wrote:
> > > > > On Sun, 6 Jan 2008, Quan phongvan wrote:
> > > > >
> > > > > > Dear friends,
> > > > > > I've just taken part into our community on apt-rpm, and I have a
> > > question,
> > > > > > hope to get yours help as soon as possible.
> > > > > > Now I have try to use all of three RPM Update tools: apt-rpm,
> yum
> > > and
> > > > > > smartpm. My target machine is running on CentOS (rpm system),
> and I
> > > want to
> > > > > > have some advices from all you about this issue: how about yum
> vs
> > > apt vs
> > > > > > smart on to be the best choice for RPM packages management
> system.
> > > > >
> > > > > Sticking with the native tools is usually the best option. Using
> > > something
> > > > > else always comes at a price (the tools are not as well integrated
> or
> > > > > whatever). Is there something specific yum (the CentOS
> native/default)
> > > > > doesn't do that you need?
> > > >
> > > > Ranting about yum the following comes to mind after a year of RHEL
> > > usage:
> > > > a) It's awfully slow.
> > > > b) The search function sucks more or less but I'm not sure if it's a
> > > poor
> > > > search inside yum or simply some bad package descriptions.
> > > > c) Sometimes I'm missing features like -d or --print-uris.
> > > >
> > > > Beside that it's doing what it's supposed todo.
> > >
> > > To be honest I haven't seen any other project with more bugs than yum.
> > > And for every new feature you get two bugs for free as well - just had
> > > some months of bad behaving yum due to its installonlyn "integration"
> > > with its depsolving extinguishing *installed* kernels out of the
> > > dependency calculations making all installed kmdls look like not
> > > having their kernel installed ... :(
> > > (finally fixed in yum 3.2.8)
> > >
> > > o smart seems to do the most intelligent depsolving (hence the name)
> > > o apt is faster than light - great for distro upgrades
> > > o yum is what everyone uses these days
> > >
> > > Or rephrased: if yum was really working satisfactorly the other
> > > projects would not exist (anymore). But there are tons of developer
> > > resources behind yum, while not so for apt-rpm or smart, so if you
> > > want to do a long time bet yum should logically become the winner.
> > >
> > > Having said that: You can use all three in "parallel" and judge for
> > > yourself after a while. you can always jump from one depsolver to the
> > > other at any later time (in "parallel": not really in two xterms in
> > > parallel, of course, but when one depsolver is finished you can
> > > immediately use another one).
> --
> Axel.Thimm at ATrpms.net
>
> _______________________________________________
> Apt-Rpm mailing list
> Apt-Rpm at lists.laiskiainen.org
> http://lists.laiskiainen.org/listinfo.cgi/apt-rpm-laiskiainen.org
>
>

-- 
Never walk alone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/attachments/20080109/edf4b104/attachment-0003.htm>