<br><br><div><span class="gmail_quote">On 2/15/07, <b class="gmail_sendername">James Sparenberg</b> <<a href="mailto:james@linuxrebel.org">james@linuxrebel.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thursday 15 February 2007 11:38:29 Marius Vollmer wrote:<br>> With a version locked meta package, we can make sure that the user<br>> gets the right combinations of packages.<br><br>umm Maybe I'm missing something but since this is debian based .deb's handle
<br>this quite well. XXX.deb can require YYY.deb version 2.1 or greater. You<br>are going to not only go nuts building meta packages but also go nuts trying<br>to re-invent in a way a wheel you already have. I can understand the meta
<br>for going from 2.0 to 2.2 for example (all done one fell swoop) but why<br>update everthing just to include a couple of K of changes.</blockquote><div><br>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). <br>
<br>
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]<br>
<br>
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.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I tried to install and test a debian armel pkg earlier today but I couldn't
<br>because a core dependency isn't met on the Nokia. No sweat, If I had had the<br>armel repository in my repositories it would have given me the full chaos of<br>the dependency chain then stopped and waited for my approval.
</blockquote><div><br>I don't know how to respond. I'm not sure quite what you're talking about... <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Be careful when protecting idiots, you usually end up losing the people you<br>want to keep and getting stuck with a load of empty heads.</blockquote><div><br>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.
<br><br></div>[1]http://people.debian.org/~tille/debian-med/talks/paper/debian-med-8.html<br><br>--Paul<br></div><br>