Re: new opie build up for testing
> Functional stuff first...I've played with these under qvfb a bit, and
> overall they seem to be working quite well. A few things:
>
> - why are both libqte2 and libqte3 required? Those are the second and third
> largest packages involved, I believe.
a bug with qte-fonts which is fixed in latest packages. (just uploaded)
> - qte-fonts is 15MB(!). We will probably need at least one stripped-down
> version containing only fonts which make sense on a particular PDA screen
> size. We can probably take hints on this from OZ.
was thinking hte same thing...figured someone would have to tell me what
that would need to be. :)
qte-fonts-minimul or -opie maybe...something like that.
> - I couldn't get reader-qte to work; it would spin forever even loading a
> small PDF. I've never tried this app before, though, so this may not have
> anything to do with the packaging.
no clue...
> Apart from these minor issues, everything worked just the way I expected.
> Great work. I may have time this evening to test building and running them
> on the Zaurus; if not, perhaps later this week.
>
> > This is for i386 only. That means we are not looking to test whether
> > the apps work on a Zaurus or iPAQ. What I need is help with
> > the Debian aspects of this. Are the files being put in the
> > proper places on the filesystem so that they both work and
> > follow Debian policy?
>
> One thing that I am concerned about is that many of the applications have
> very generic names ("sound", "reader", "go", "apm", etc.) which are bound to
> either conflict with other packages in Debian, or simply be inappropriate
> for /usr/bin.
>
> This is not much of a problem on a handheld environment, of course, since
> they won't generally be sharing this real estate with very much other
> software, and the names make sense there, but one of the nice things about a
> Debian-based setup (at least to me) is the ability to very quickly and
> easily throw the applications on a desktop to test, debug, etc. For
> example, I just installed pretty much all of your packages on my desktop
> machine to experiment, and have a very loaded qpe menu and taskbar now. :-)
>
> Maybe we should think about adding a prefix to the binaries?
We could do this but I think it should be for only those apps who has very
generic binary names such as reader and sound.
> > Is the package layout proper? Are there
> > packages which should be merged with others or are there apps
> > that should be broken out into their own packages? Things like
> > that.
>
> If you followed the ipkg structure (and it looks like you did), then the
> package subdivisions should be more than fine, but hopefully others with
> more experience with the micro-distributions can speak to that. The file
> placement looks fine as well; I see nothing that seemed misplaced.
heh..I just move things around again. :) but not by much.
>
> > it. So what does this mean to you? Well, it means that from a
> > single source package I ended up with something like 142 packages.
> > I had thought that I had a crapload of packages when I was dealing
> > with all the KDE stuff but damn! :) I'm going to hear it from
> > the ftpmasters when I go to upload this so lets be sure to make
> > sure this is what we want. My opinion is that it's for Embedded
> > systems so the ability to pick exactly what you want installed
> > and limit the size of your system is *very* important.
>
> It would help a lot to break Opie up into several source packages (like
> applets, games, apps, etc.), and maybe even break out some of the larger
> apps into their own source packages. This way, we can easily update parts
> of the system without introducing 142 packages worth of churn.
ohhh...now that's a very good idea. Maybe we should try to get upstream
to do this at their level.
> > umm..and finally something that I was thinking as I was looking at all of
> > these damn packages. I think we might need a new package section. Some
> > sort of Embedded section equivilant to X11 which currently exists. In
> > trying to figure out what sections all of these packages belong to (which
> > is another thing I need people to help with) I kept wanting to put things
> > in x11. This would not (of course) be accurate since they are not x11
> > apps. Maybe we need a "embed" section for these. What do you think?
>
> An "embedded" or "handheld" section would be ideal, though I've no idea
> whether it will get support from ftpmaster. Of course, most of these
> packages might better fit into existing categories, but we'll definitely
> want some way to filter them out in order to present them alone in a
> simplified package installation tool (like aqpkg), and a section would be
> the most natural way to accomplish this.
>
> We may need to establish our own package repository, at least in the
> interim.
well I can definatly keep these up on p.d.o for the time being. I'm nowhere
ready to upload to Debian proper as I'm still futzing with package names and
everything else.
I'm working on -x11 versions right now..well, not really too much work. Found
out what needed ot build and copied my tree over, hcanged package names and
whatnot and kicked off a build.
I also changed the package name extension from -qte to -fb. and the x11
packages will be -x11.
the new -fb named packages with new file layout are up right now. Just
rebuilt the Packages file. Seems to work fine.
next process for all of this I think will be source breakout as you suggested.
Proper process I guess would be to first breakout the core libraries: libqpe
and libopie. Then I guess I'll just follow the sections listed in the
make menuconfig. That would break it down to about 12 source packages. That
should at least make it 12 times easier to deal with. :)
Ivan
--
----------------
Ivan E. Moore II
rkrusty@tdyc.com
http://snowcrash.tdyc.com
GPG KeyID=90BCE0DD
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Reply to: