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

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.laiskiainen.org/pipermail/apt-rpm-laiskiainen.org/attachments/20080108/2c72b814/attachment-0003.pgp>