Re: new opie build up for testing
On Tue, Feb 04, 2003 at 04:50:34AM -0700, Ivan E. Moore II wrote:
> Ok, a few more days of work and I now have new packages up for testing and
> they are apt'able.
>
> deb http://people.debian.org/~rkrusty/ opie unstable
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.
- 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.
- 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.
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?
> 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.
> 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.
> 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.
--
- mdz
Reply to: