On 2/15/07, James Sparenberg <james at linuxrebel.org> wrote: > > On Thursday 15 February 2007 11:38:29 Marius Vollmer wrote: > > With a version locked meta package, we can make sure that the user > > gets the right combinations of packages. > > umm Maybe I'm missing something but since this is debian based .deb's > handle > this quite well. XXX.deb can require YYY.deb version 2.1 or greater. You > are going to not only go nuts building meta packages but also go nuts > trying > to re-invent in a way a wheel you already have. I can understand the meta > for going from 2.0 to 2.2 for example (all done one fell swoop) but why > update everthing just to include a couple of K of changes. I'm not sure you understand how metapackages work in debian--or maybe I don't. Meta-packages are essentially virtual packages. They don't do anything on their own, but have as dependencies lots and lots of other packages. This means that instead of installing 300 some packages for the Maemo system, you have 1 meta package that has 300 some dependencies. Specific, version strict dependencies--although as you mention, it could be done with "version or later" dependencies). There won't be lots of meta packages, there will be one. When a system package needs to be updated, a new version of the meta package will go on the repository with a few of it's dependencies changed. A user clicks "check for updates" and these new packages are requested for update. Those packages that are already installed that don't need to be updated won't be. A meta package is not some giant package that contains everything, it is actually a package that contains absolutely nothing at all, it just requires lots of other packages before it can be installed. Please read on for more information [1] What this will mean is that you can update the system incrementally, exactly like Redhat, Suse, etc managed by YUM, or Debian, Ubuntu, etc managed by aptitude. What's different is because Nokia provides tech support, they don't want to support the newest version of package X until they are ready and have fully tested it, so even if someone in the community builds package X AND X is part of the main system, you won't be able to upgrade without going to red pill or using apt-get. However, /you will still be able to install the package by going to red pill or using apt-get/ and this will /only/ effect main system packages. I tried to install and test a debian armel pkg earlier today but I couldn't > because a core dependency isn't met on the Nokia. No sweat, If I had had > the > armel repository in my repositories it would have given me the full chaos > of > the dependency chain then stopped and waited for my approval. I don't know how to respond. I'm not sure quite what you're talking about... Be careful when protecting idiots, you usually end up losing the people you > want to keep and getting stuck with a load of empty heads. Please re-read the original post for this thread and look at the proposition. They really aren't protecting idiots so much as offering a safe way to provide incremental upgrades, just like desktop linux systems. [1]http://people.debian.org/~tille/debian-med/talks/paper/debian-med-8.html --Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maemo.org/pipermail/maemo-users/attachments/20070215/104b0d26/attachment.htm
