Current Opkg Status

Paul Sokolovsky pmiscml at gmail.com
Thu Feb 21 23:30:38 CET 2008


Hello,

On Thu, 21 Feb 2008 21:07:46 +0000
Thomas Wood <thomas at openedhand.com> wrote:

[]
> >>> Finally, thanks for starting on decent embedded package manager.
> >>> And I hope that you considered different alternatives. For
> >>> example, I last time pondered idea to prototype something in
> >>> Vala. I mention this because I found ipkg code to be pretty
> >>> dirty, and just clean up of it would take effort.
> >>
> >> This is actually a great thing, but at OpenMoko we found the need
> >> to improve the existing package manager due to time constraints
> >> (isn't it always like that?).
> >
> > Yes, always ;-). And my pondering was mostly of speculative manner -
> > I don't have plans to start on that anytime soon ;-). Because Vala
> > implementation wouldn't be w/o issues either. For example, it would
> > need be linked statically with glib, and I doubt it would be less
> > than 500k+ monster. And after all that, it would need to make
> > people use such a completely new package manager, which is a task
> > in itself. So, if
> > even big company selected to elaborate existing implementation,
> > then no little guy in sober mind would invest into that ;-).
> 
> Why would it need to be statically linked? Personally, I would like
> to see opkg link to glib as it would help to clean up and optimise
> lot of the memory allocation and string handling code. Opke already
> links to two new libraries (curl and gpgme). Since glib is likely to
> be in the base installation of any modern linux distribution, I don't
> think it's a problem.

Hm, yes, that's kind of old-school reasoning that package manager
should be as self-contained as possible, so if during upgrade something
goes wrong, then at least the package manager itself remains usable. But
depending on more libraries for more functionality is unavoidable
evolution I guess, so it indeed becomes blurred.

> 
> And please note I would not intend on including and gobject 
> dependancies with libglib.
> 
> >
> >> Personally, I'd welcome a clean start in Vala
> >> though...
> >>
> 
> I'm not sure what advantages vala would actually bring. I don't think 
> object orientation is always necessary to  improve a piece of
> software. Sometimes keeping it simple is best.

Sure, raw C always rules, if it's manageable ;-). Regarding Vala, I'm
hinting at native support for Lists and Mappings, manipulating which is
of course main internal work of package manager, so it should be fairly
easy to make initial prototype, which yet could lead to something
actually usable in real world thanks to compilation to binary. (There
were talka about re-prototyping ipkg in Python before, for example, but
usefulness of such implementation is doubtful.)

> 
> Regards,
> 
> Thomas
> 

[]

-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com




More information about the opkg-devel mailing list