Hi All,
I'd like to discuss a few things that I think are basically some inherent weaknesses in pdaXrom, or rather its development philosophy. Please don't get me wrong as I actually quite like pdaXrom and I think there’s been an exceptional amount of good work put into it by the developer(s), and I must also applaud those who package and contribute applications. You just need to look at
http://mail.pdaxrom.org to see the amount of good work put in.
However my concern is that the design of pdaXrom currently prohibits its expansibility and has some pretty big risks.
What are some of the big questions that are always asked in the forums? They are things like this: -
- Where do I find the feed for (some older version)?
- Please could someone port app from (newer/older) feed to (older/newer) feed?
- Where can I find (appname)? It used to be here, but its not here any more.
Currently, from my perspective, an image of a version of pdaXrom is released periodically through the efforts of sashz and Laze. These may or may not work with existing feeds (including contributed ones), and generally kind developers on the forums scramble to ensure that packages they've released still work and still have the proper dependencies etc..
My worry is that this process has the following flaws: -
-
The 'hit by the bus' issue - What if a core developer disappears/gets sick of the project. What happens to the project? Is it capable of surviving? What happens if sashz is burned out and feels that he is obligated now to keep developing since everyone is depending on him? That’s quite a bit of stress!
-
Effort to create a package - There seems to be a lot of effort needed to generate packages. Once generated, people are reluctant to necessarily update these packages unless they are actively using them as they need to almost reproduce the effort to create it in the first place unless they're smart enough to keep good logs or have a good make script.
-
Effort to create a public package - Due to the above point, it’s possible that people who could package something for the public may decide against doing it as the effort may only work for the current release of the 'rom'.
-
Lost Compiling Information/Source code - How someone packaged something (including patches) seems to be lost. This actually breaks GPL. It also means that should this person be 'hit by a bus' etc.. someone else has to re-work out how to package the app.
-
Old Version Maintenance - Old versions. Most distributions will 'backport' fixes to old versions for a period of time. Currently as soon as a release is made in pdaXrom, the old feed is 'frozen' and it used to be lost. I'm talking about non-core feeds here as well (i.e. contributed ones that may/may not with other versions of pdaXrom). No back porting is really done.
-
Dependancy Change Issue - If a major library changes (IE, say libc, glibc or something everything depends on), too many contributed packages will break! Same old story, who will go through the steps to repackage them (talking about contributed as well as core feeds)? In fact, it may take a while before someone realises the package doesn't work if it’s not too popular a package.
I really don't wish to see a project like this die because of one of these flaws. Something that most distributions have is the following: -
- Version control with full logging and accessible access to the code. All of it!
- A method of generating a new feed (by compiling everything based on rules/recipes) when new versions that may break old feeds come out
The advantages, especially of the latter point are: -
-
Rule based packaging - If I want to package something, I create a recipe/rule for it safe in the knowledge that most likely this same rule/recipe will work to recompile the package for future versions. I can submit this somewhere and know that someone else can run the 'rule' and get a package. This takes lots of things out of the equation
-
Effort expended only once - Because I only really have to use the effort once to create the rule/recipe I'm more likely to create packages. If I'm bored, I'll just randomly pick one and create it. Then forever more that package (possibly with minor tweaks to the rule/recipe) will be available.
What I'm describing as most of you may already know is already provided in the OpenEmbedded framework. I realise there has also be friendly (and some unfriendly) rivalry between OpenZaurus and pdaXrom, but I think that no one can disagree that OpenEmbedded does a pretty good job and takes a lot of risk away. I'm not saying this is the only way, but a lot of the work is already done here.
I decided the other day to backup my pdaXrom installation, install OZ/GPE and try out OpenEmbedded to compile things. I haven’t before because its scary learning something new and I'd heard that OpenEmbedded was a bit difficult. I took my time tracking app (Gtimer) that I use (and normally use in a debian chroot) as my challenge to package. It’s a bit of a complicated package in that debian provides quite a big patch for it (the author no longer maintains it), it’s still packaged for the older debian system (IE, the original_tar is a tar of a tar.bz2) and uses libgtk1.2. It took me 30 minutes to work out how to use OpenEmbedded (to compile nano as an example...), then 1 hour to muddle my way through to create a recipe that downloads, extracts, patches, compiles and packages gtimer (and the end recipe is only 14 lines long!!). I can submit this and know that gtimer will always be around now (since the whole feed is compiled for each version), and if I get 'hit by a bus', someone else surely can fix a 14 line file. And someone will KNOW it breaks because the WHOLE feed is compiled every version and non-compiling packages will be flagged. I also don't have to figure out how to create a tool-chain or any of the dependency libraries as they are compiled by OE automatically as part of creating my package.
What I would like to ask is if pdaXrom developers please (please!) could seriously consider using this valuable tool (or an equivalent if it exists). You can (and probably should) have a totally separate 'branch' from OpenZaurus dedicated to the pdaXrom style that people could contribute recipes to... and it also means that probably with minimal tweaking, rules can be take from the '.dev' and '.oz354x' branches and vice versa. It means that you're still 'separate' but that everyone can contribute and maintain what is a very good OS.
What do other developers and users think? This is NOT a flame starter and NOT a this-rom is better than that-rom thread! It is simply my concern that I wish to express!
- Bundabrg
Show Posts