<br><br><div><span class="gmail_quote">On 2/15/07, <b class="gmail_sendername">James Sparenberg</b> &lt;<a href="mailto:james@linuxrebel.org">james@linuxrebel.org</a>&gt; 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>&gt; With a version locked meta package, we can make sure that the user<br>&gt; gets the right combinations of packages.<br><br>umm Maybe I&#39;m missing something but since this is debian based .deb&#39;s handle
<br>this quite well.&nbsp;&nbsp;XXX.deb can require YYY.deb version 2.1 or greater.&nbsp;&nbsp;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.&nbsp;&nbsp;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&#39;m not sure you understand how metapackages work in debian--or
maybe I don&#39;t. Meta-packages are essentially virtual packages. They
don&#39;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 &quot;version or later&quot; dependencies). <br>
<br>
There won&#39;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&#39;s dependencies changed. A user
clicks &quot;check for updates&quot; and these new packages are requested for
update. Those packages that are already installed that don&#39;t need to be
updated won&#39;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&#39;s different is because Nokia provides tech
support, they don&#39;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&#39;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>&nbsp;</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&#39;t
<br>because a core dependency isn&#39;t met on the Nokia.&nbsp;&nbsp;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&#39;t know how to respond. I&#39;m not sure quite what you&#39;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&#39;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>