[Apt-Rpm] Apt-rpm on embedded Linux, is it impossible?
Quan phongvan
phongvan84 at gmail.com
Mon Jan 14 00:35:32 PST 2008
Dear jean-seb,
I'm so surprised at receiving your reply so fast, thank you very much.
But if you don't mind, may i ask you a favour to help me clear out some
issues that confused me.
1. As you mentioned: "I tested urpmi, apt and yum". While you tested both
three update tools: urpmi, smart, apt, what were the most important aspects
that had impacts on your judgement for choosing the best update tools
candidate (in your case is apt-rpm). And comparing to urmpi and yum, what
were obstacles that make urpmi and yum did not match with your requirements
as a update tool?
2. As I knew, apt-rpm has LUA as a interpreter embedded language that
provide users a lot of powerful option in apt-* command line, because I'm
just beginner in LUA, can you give more instructions and advices to skilled
in LUA as apt-rpm power tool (I easily followed the intructios that
apt-rpm.org provides but I think they not enough for me toseriously use it).
3. Because my progess is under investigeting phrase and I'm still
transparent from my target machine's configuration, so I'm sorry that I
doesn't have more specified specs for you. If you don't mind, I hope to
receive your help in near future for that issue.
Hope to see your reply soon.
Best regards,
Nguyen Anh Quan.
On Jan 14, 2008 2:20 PM, js <jsh at interlug-fr.org> wrote:
> Quan phongvan wrote:
> > Dear Jean-seb,
> > It's so kind of you to answer all of my issues with very useful
> > informations. I really appreciate it.
> > But I still have some things from your reply, and I hope that you can
> > clear them for me, thank you in advance.
> > 1. You mentioned: "No, it use apt only, personally I hate yum and
> > don't understand why create an other tool for rpm based distro, apt
> > was already here and do the work well; and the best,". I think that
> > while yum has released its stable version so long time ago, apt-rpm is
> > still under developing (testing version). In addition, yum has a huge
> > developer resource behind, if we consider update tool from business
> > point of view, can yum become a update tool candidate?
>
> Linux, the glibc, gcc, KDE are still in development too :)
> apt is very very stable and do the job nicely for years (I use the old
> apt from conectiva, before to update to the Lorg version).
> That's not because apt is still in devel than it is not ready for
> production.
>
>
> > 2. About yum and python, I was already clear, thank you for your
> > model, it's so easy for me to understand the problem. If you don't
> > mind, have you ever tried smartpm as a update tool on your embedded
> > system (smartpm similar to yum and apt-rpm, it uses python also), if
> > yes do you have any advice for me about smartpm?
>
> smartrpm??? I never test it.
> apt was used by conectiva linux for the whole distro, but smartrpm not
> .... and smartrpm was too young 3 years ago.
> Maybe now, you can take time to test it and see if it is the good tool
> for you.
> To me, an important thing was to have one update tool for both Debian
> and Rpms distro; so ... apt was used :)
> yum was ... sorry but, a real crap (I tested urpmi, apt and yum)
>
> > 3. My target system run on a very tiny Linux clone (mini-ram embeeded
> > Linux - RPM system, like VxWorks), it lacks development tool such as
> > gcc and XWindow, so will apt-rpm run well on these systems?.
> I think, yes.
> You have some specs??
>
>
> > Beside, our update tool connect Internet through firewall for security
> > purpose to do system-update, so we must consider some security issues
> > such as: session hijack or disguise of server. Do you have any
> > comments for me with apt-rpm to deal with these problems?
> All the rpms are signed, and don't install if the rpm is not signed with
> the right gpg key :)
> This is in the apt-get lua config (see /etc/apt/apt.conf :
>
> Scripts
> {
> Init { "gpg-import.lua"; };
> PM
> {
> Pre { "gpg-check.lua"; };
> Post { "upgradevirt.lua"; };
> };
> AptGet
> {
> Upgrade { "upgradevirt.lua"; };
> DistUpgrade {"upgradevirt.lua"; };
> Install::SelectPackage { "upgradevirt.lua"; };
> Install::PreResolve { "upgradevirt.lua"; };
> Install::TranslateArg { "upgradevirt.lua"; };
> };
> Synaptic
> {
> DistUpgrade { "upgradevirt.lua"; };
> }
> }
>
>
> So, if a bad guy changes one or more rpms, they will not be installed,
> and the only way to install them will be to deactivate the gpg-check.lua
> script
> or use the command rpm -ivh yourRPM.rpm by hand.
>
> Regards
>
> js.
>
>
>
> > Thank you very much.
> > Hope to see your reply soon.
> > Best regards,
> > Nguyen Anh Quan.
> >
> >
> > On Jan 13, 2008 12:09 AM, jean-seb <jsh at interlug-fr.org
> > <mailto:jsh at interlug-fr.org>> wrote:
> >
> > Quan phongvan a écrit :
> > > Dear Jean-seb,
> > > It's so nice for me to hear that from you. If you don't mind,
> > can you
> > > give me more advices for my issues:
> > > 1. For your mentioned RHEL clone that you used on your embedded
> > > system, Does it have yum as RPM packages management systems. If
> yes,
> > > can apt-rpm beats yum as a update tool?
> >
> > it is use in Debian and Rpm based distro, so when you swith into
> > Debian
> > and Rpm distro, no problem: apt-get update, apt-get dist-upgrade
> > ... :)
> >
> >
> > > 2. As you mentioned "apt is faster than light , and it don't need
> > > python; so the memory it use is not a big issue.", I think
> > apt-rpm has
> > > a big dependency list (especially when I compiled apt-rpm from
> > source
> > > code, it required a lot of packages such as: beecrypt, zlib,...).
> > > About python, does it really become the most biggest obstacle
> > for yum
> > > or even smartpm (an update tool for RPM packages similar to yum
> and
> > > apt-rpm).
> > Yum use python and a lot of sub-modules (how it query the rpm
> > database?);
> > the main problem I see: you need a pre-interpreter to run yum:
> > So you can resume it by:
> > kernel -> glibc -> python -> pre-compiling -> yum+ extra modules
> >
> > for apt:
> > kernel -> glibc -> libs (stdc++, zlib) -> apt
> >
> > Pre-compiled software runs always faster ( C and C++ are faster than
> > Python).
> >
> > If you have time: you can test this 'theory' with gdb and see what
> > program (yum or apt) use the most of memory :)
> >
> >
> > > 3. In addition, can you give more details why did you mention
> > about HP
> > > Server ProLiant in: "it is faster that the same version in
> Proliant
> > > Servers ! (maybe because /var is in ram?)".
> >
> > We use one distro (Gralinux AS 3; a RHEL clone with some tweaks;
> > webmin,
> > openvpn, more iptables modules etc..) on both Embedded systems and
> > Servers: the binaries are strictly the same.
> > we have a lot of HP proliant and when i apply updates, apt is far
> > faster
> > on embedded devices than on the big Proliant :) : a read/write issue
> i
> > think ;)
> > We all know than hard drive are .. slow :-/ , specially with Raid
> > 5 ...
> >
> > > Hope to receive your advice soon,
> > > Best regards,
> > > Nguyen Anh Quan.
> >
> > Regards
> >
> > js.
> >
> > Air-Austral flight Company.
> > http://www.air-austral.com
> >
> > >
> > > On Jan 11, 2008 7:13 PM, jean-seb <jsh at interlug-fr.org
> > <mailto:jsh at interlug-fr.org>
> > > <mailto: jsh at interlug-fr.org <mailto:jsh at interlug-fr.org>> >
> wrote:
> > >
> > > Quan phongvan a écrit :
> > > > Dear friends,
> > > >
> > > > I've studied apt-rpm as a candidate update tool for RPM
> > packages
> > > > management system, because my target device run on
> > embedded Linux
> > > > (like Vxworks - an RTOS of windriver).
> > > > If you don't mind, I hope that someone has tried using
> > apt-rpm on an
> > > > embedded system such as VxWorks and can share me his
> > experiences. I
> > > > really appreciate it.
> > > > Thank you for your attention,
> > > > Nguyen Anh Quan.
> > > > --
> > > > Never walk alone
> > > >
> > >
> > > I use apt in a RHEL clone for embedded systems (openvpn,
> > firewall and
> > > tons of stuffs like snort etc..):
> > > it runs on a Via C3 533Mhz, 512Mo ram (256 for the system
> > memory, and
> > > 256 for /var and /tmp in read/write mode);
> > > the rest of the system is on a CF 512mo in read only (ext3
> with
> > > some tweaks)
> > >
> > > apt is faster than light , and it don't need python; so the
> > memory it
> > > use is not a big issue.
> > >
> > > it is faster that the same version in Proliant Servers !
> (maybe
> > > because
> > > /var is in ram?)
> > >
> > > A good choice for a "big" embedded system.
> > >
> > >
> > > Regards.
> > >
> > > js
> > >
> > > Air-Austral flight Company.
> > > http://www.air-austral.com
> > >
> > >
> > > _______________________________________________
> > > Apt-Rpm mailing list
> > > Apt-Rpm at lists.laiskiainen.org
> > <mailto:Apt-Rpm at lists.laiskiainen.org> <mailto:
> > Apt-Rpm at lists.laiskiainen.org <mailto:Apt-Rpm at lists.laiskiainen.org
> >>
> > >
> > http://lists.laiskiainen.org/listinfo.cgi/apt-rpm-laiskiainen.org
> > <http://lists.laiskiainen.org/listinfo.cgi/apt-rpm-laiskiainen.org>
> > >
> > >
> > >
> > >
> > > --
> > > Never walk alone
> > >
> >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Apt-Rpm mailing list
> > > Apt-Rpm at lists.laiskiainen.org <mailto:
> Apt-Rpm at lists.laiskiainen.org>
> > >
> > http://lists.laiskiainen.org/listinfo.cgi/apt-rpm-laiskiainen.org
> > <http://lists.laiskiainen.org/listinfo.cgi/apt-rpm-laiskiainen.org>
> > >
> >
> > _______________________________________________
> > Apt-Rpm mailing list
> > Apt-Rpm at lists.laiskiainen.org <mailto:Apt-Rpm at lists.laiskiainen.org>
> > http://lists.laiskiainen.org/listinfo.cgi/apt-rpm-laiskiainen.org
> >
> >
> >
> >
> > --
> > Never walk alone
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Apt-Rpm mailing list
> > Apt-Rpm at lists.laiskiainen.org
> > http://lists.laiskiainen.org/listinfo.cgi/apt-rpm-laiskiainen.org
> >
>
> _______________________________________________
> 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/20080114/d7c58011/attachment-0003.htm>
More information about the Apt-Rpm
mailing list