Package management?

[Toby Smithe]

On Thu, 2006-09-07 at 00:21 +0200, Stefan Sperling wrote:
> On Wed, Sep 06, 2006 at 10:42:38PM +0100, Toby Smithe wrote:
> > We would need a method to convert the current Makefiles to the new
> > system. The best approach, surely, would have this task automated.
> 
> No - this would be the most impractical approach.
> Computers are stupid. You'd have to convert the Makefiles manually.
> There's too much diversity in the Makefiles in our tree.
> 
> By the way, if we managed to add *exactly* 11000 more Makefiles
> to our tree, we've have a lucky number:
> 
> [stsp at ted ~/dslinux/src]$ find . -name Makefile | wc -l
>     1345
> 
> > I don't know enough about buildroot, say - if we were to implement that,
> > to know if that is possible.
> 
> If you really want to go for buildroot, I guess the best way
> is to start a new buildroot fork from scratch, integrating
> dslinux-related stuff by hand, effectively breaking the history
> of the dslinux tree. That should be less work than trying to nail
> buildroot onto uClinux. 
> 
> I still think that sticking some hooks into the uClinux Makefiles
> to generate ipkgs would be less painful. The question is how to do
> this in detail, and how to limit conflicts with upstream as much as
> possible. I guess it should mainly be implemented in new files.
> Modifications of upstream Makefiles may be inevitable, but should
> be kept as small as possible.

If I were to implement this, then this is probably the way I would go to
start with. However, moving to buildroot first might make life easier in
the future.

I was also wondering whether we should have ipkg handle dependencies. If
so, then I would somehow need to compile a dependency tree. Any ideas?

Notwithstanding these, I'm not promising anything ;-) !

> I am still fine with the current situation by the way - I don't
> see much reason to change the build system just for the ram build.

But I'm sure users would like a repository system, especially if they
have used Debian.

> But I won't stand in the way of good solutions for a package system
> either. In fact, I (and others, likely, too) would like to see much
> more consistently active contributers to the project in general, so
> new ideas (and revival of old ideas) are always good and welcome :)

I agree with you here, and I would surely contribute if I had the savoir
faire.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mailman.dslinux.in-berlin.de/pipermail/dslinux-devel-dslinux.in-berlin.de/attachments/20060907/84c5b086/attachment.pgp