Re: Separate cache folders for undigest mirrors

[Indigo <pointofavailability@xxxxxxxxx>]

Let's remember the importance of keeping the permissions right for the
root user.  A regular user should not have the ability to change
settings in /etc or alter /var/cache -- I do like the idea of using
the home= boot option, though.  My idea is this:  lets make a
/home/root folder and just symlink /root to it.  In the /home/root
folder, we can have a cache directory, as well as the slitaz directory
(only a root user should be able to generate a new iso from the
existing filesystem, anyway) -- the permissions could remain
root:root, and this could facilitate a writable place for changes in
the root filesystem.  By this, I mean that the root user could make a
custom /etc/network.conf, or whatever, and have it persistent for the
next boot.  We could do away with /etc/skel also, as I suggested
before, and have one place for customizations that wouldn't affect
$user directories or the rootfs... this would mean that a user could
reboot into a completely different flavor, or custom package list, and
not lose display settings or wireless configs.


On Tue, Dec 14, 2010 at 3:00 PM, Christopher Rogers
<slaxemulator@xxxxxxxxx> wrote:
>>The goal of home= boot option is precisely to use an external devide
>>instead of having a home in RAM, so I don't see how it will make grow
>>the RAM requirement to 2GB. It's the exact opposite : Having the cache
>>folder on /home will avoid keeping all downloaded packages in RAM ! and
>>will avoid re-download them at each session. And you can mount
>>absolutely what you want as home (i.e: liveCD+home on hdd; usb+home
>>from an encrypted file; etc).
>
> I was talking when you were said that the livecd could be 700mb. (Like puppy
> linux multisession or something.) This is without the home= option. Even
> with home= option your still not going to have your custom packages that you
> installed to system. Also since its only saving to home folder everything
> else is still in RAM. You will not save /etc folder. You will not save any
> other folder other than /home.
>
>> I also use my modular-slitaz that has changes boot option. This saves
>> everything that is not from the livecd into changes folder on my hard
>> drive.
>> The home= boot option you also don't have system settings from /etc folder
>> too.
>>
>> With the way sitaz works the make a full 700mb cd would take over 2gb of
>> ram
>> just for the filesystem. This is cause everything is uncompressed from
>> initramfs file into ram. Also this would cause slitaz to be slow to boot
>> and
>> buidl the iso.
>
> I said in the quote uncompressed 700mb cd/rootfs.gz = OVER 2GB.  I was not
> talking about home= option in 3rd paragraph.
>
> I hope this helps.
>
> PS I can talk to you better in irc then email. Sorry about my confusion.
>
>
>
> On Tue, Dec 14, 2010 at 10:37 PM, GoKhlaYeh <gokhlayeh@xxxxxxxxxx> wrote:
>>
>> On Tue, 14 Dec 2010 20:44:55 +0000
>> Christopher Rogers <slaxemulator@xxxxxxxxx> wrote:
>>
>> > The /home/slitaz folder is a bad idea since most development folders on
>> > tank
>> > go there. That could cause confinct with there being to many folders
>> > there.
>>
>> As you know, I made some changes recently in tazpkg. Before that,
>> tazpkg copied packages info files from local repository
>> (/home/slitaz/$release/packages) into the /var/lib/tazpkg; and copied
>> packages from local repository to cache dir (/var/cache/tazpkg). Now,
>> it uses symlinks instead; so virtually cache and local repository **are
>> already merged**. It doesn't complexify anything and save a lot of
>> ressources. Then, about undigest : as you push the m5sum verification
>> in tazpkg, here's whats going on : if names overlaps, it replace the
>> symlink to a repository (lets
>> say /home/slitaz/cooking/packages/pkg.tazpkg) by a symlink to the
>> desired one (i.e. : /home/slitaz/undigest/packages/pkg.tazpkg). So once
>> again, all run as cache dir and local repo are merged actually; and
>> it's precisely based on tank directory structure = no problem here,
>> even with multiple repositories using the same cache. I was talking
>> about desirable changes to make things better, because there's really
>> no problem with actual behavior. About info files : the side-effect of
>> using symlink is that tazpkg recharge is needed only once time; then
>> info files linked from local repository are always up-to-date :)
>>
>> > Also this would require a rewrite of most tools that look at CACHE_DIR
>> > path.
>> So : tazpkg, as the only other occurence to CACHE_DIR in SliTaz tools
>> is a line in tazlito which try to link packages from cache directory to
>> the local directory...
>>
>> > I also use my modular-slitaz that has changes boot option. This saves
>> > everything that is not from the livecd into changes folder on my hard
>> > drive.
>> > The home= boot option you also don't have system settings from /etc
>> > folder
>> > too.
>> >
>> > With the way sitaz works the make a full 700mb cd would take over 2gb of
>> > ram
>> > just for the filesystem. This is cause everything is uncompressed from
>> > initramfs file into ram. Also this would cause slitaz to be slow to boot
>> > and
>> > buidl the iso.
>>
>> The goal of home= boot option is precisely to use an external devide
>> instead of having a home in RAM, so I don't see how it will make grow
>> the RAM requirement to 2GB. It's the exact opposite : Having the cache
>> folder on /home will avoid keeping all downloaded packages in RAM ! and
>> will avoid re-download them at each session. And you can mount
>> absolutely what you want as home (i.e: liveCD+home on hdd; usb+home
>> from an encrypted file; etc).
>>
>> > I just think its better to use the /var/cache/tazpkg/undigest/$repo path
>> > for
>> > undigest for now. We should just work on make home= boot option work
>> > more
>> > like changes boot option in modular-slitaz.
>>
>> I don't see the point about home= boot option. I disagree with your
>> criticals but obviously you can proceed to this change if you want to.
>> Hoverwhere, I think having the cache on a peristent home will be a
>> great improvement and I intend to code this someday.
>>
>> Peace,
>>
>> --
>> GoKhlaYeh <gokhlayeh@xxxxxxxxxx>
>>
>>
>> ---
>> SliTaz GNU/Linux Mailing list - http://www.slitaz.org/
>>
>
>

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