Re: previous version of packages on mirror

[Indigo <pointofavailability@xxxxxxxxx>]

I agree, for the most part.  Especially for things like the kernel,
where even the source should still be available, it is necessary to
keep those packages.  The cooking ISO comes with kernel 2.6.34, and it
should absolutely be supported.  Considering the cooking version is
basically testing level, major changes should not obfuscate packages
found on the downloadable liveCD.  But minor changes, and version
updates to less significant packages would not really matter.

On your point about 2.6.36 overwriting 2.6.34, however, this is not
the case on my install.  But I do want to suggest that when
/boot/grub/menu.lst is altered, the new kernel should become the
default.  The way it stands now, a user has to correct the file
manually.  Regarding the forum discussion, well, Xorg is an issue of
it's own -- the reason it's not working, in most cases, is a lack of
hardware detection and Xorg simply chooses default refresh rates that
are inadequate for newer hardware (related to the udev issue?)... I
think the other issues, involving dependencies, have been solved.

Also, as I've tried to recompile the 2.6.36 kernel to include and
automount the udevtmpfs, VirtualBox keeps failing.  It causes my host
machine's xserver to freeze if allowed to use the i/o cache, but
without it Slitaz segfaults before 'make' can complete.  For my main
system, I run Arch Linux with dual monitors, TwinView configured.  I
did update the system recently, though, and I do not know if this
problem is with Slitaz or the host (hopefully not a hardware
issue!)... at any rate, 2.6.34 never did crash on me, which is why I
bring this up.

The problem with /lib/modules is a bit trickier.  If the package
receipt is changed, then the new (or the old) kernel would become a
dependency.  I can't think of a good way to deal with this kind of
issue, but I think it's probably a good practice to release a new ISO
whenever there's a new kernel, and also to update all of the receipts
in the repo to reflect that.  Unfortunately, this would make an
upgrade mandatory for anyone with a previous version... should the
kernel just not be upgraded until cooking becomes stable?


On Sun, Nov 14, 2010 at 8:59 AM, Rohit Joshi <rj.rohit@xxxxxxxxx> wrote:
> Hi,
>
> We, currently, remove all the old version of packages from the cooking
> mirror when a upgrade version is pushed. The result is that the cooking
> mirror does not seem to have any linux-2.6.34 packages (default linux kernel
> supplied with the latest cooking). I believe this was done to save the
> hosting space. If we have enough hosting space now, can we change "rm" to
> "cp" and keep the old versions too. We have kind of lost the capability to
> backtrack to the previous pkg version using the tazpkg. This forum post is
> also related to this issue :
> http://forum.slitaz.org/index.php/discussion/comment/9804/#Comment_9804
>
> Other related issue is that "tazpkg upgrade" in the latest cooking seems to
> overwrite and remove the previous kernel completely. I used to like the old
> behavior where it will not remove the previous version of my kernel (maybe
> this interesting behavior was because of some bug that got fixed). But this
> is helpful in case upgrading to the new kernel has some hardware or other
> issues. Atleast then, I can just boot into my working copy of the kernel.
>
> Please see if we can improve these issues.
>
> Rohit
>

---
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/