Re: UnionFS Package Management
On Tue, Jan 25, 2011 at 11:11:14PM +, Ken Moffat wrote: > > but two took were more severe and > took a lot longer to fix hmm, I might be more thunk than I drink I am ;) ĸen, who admits to celebrating the 'Immortal Memory' on the 25th. -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: UnionFS Package Management
On 01/25/2011 02:10 PM, Mike McCarty wrote: > Pursuing the subject of package management, I've been considering > the use more than one of the hints. One hint I've explored somewhat > is the Package User hint. I must admit, that while it's simple, > and attractive, I don't like burdening something which isn't intended > to track packages, namely user names, with that task. However, I do > like the additional security provided by having more or less normal > users rather than root doing maintenance. > > Another idea I like quite a bit, having used it with similar version > control systems and package managers, is using a fake root build, > that is, installing to a destination other than the final one for > test before final install. > > I've been pondering the adavantages of combining the Package User > with the Fake Root, and it appeals to me. > hints/downloads/files/more_control_and_pkg_man.txt > hints/downloads/files/fakeroot.txt > (possibly also crab) > > However, after giving some consideration to the UnionFS Hint, I > wonder whether it might not go one step beyond the Fake Root. > hints/downloads/files/pkg_unionfs.txt > > I see that it's not quite as simple as the author presents, since it > requires kernel patches and significant modifications to the > initialization process. However, it doesn't look all that difficult, > and fairly straightforward. It does require some "holding one's tongue > just right". > > However, I've heard rumors about UnionFS not being quite robust, > and wonder about that. I also note that it hasn't been put in > upstream, nor has its competitor AUFS. > > I'd like to open discussion of relative merits and demerits. I like > the ability to load and unload packages "live", and give things > a test drive before commiting to them. > > I'd like others who have spent some reasonable amount of time thinking > about using the UnionFS approach to comment, both advantages and > disadvantages, and whether AUFS might be better and why. > > Mike I've been pursuing the UnionFS hint quite a bit over the past couple years, though each attempt has either failed or I just never had time to finish it. The biggest problem is that I don't know how to get UnionFS/AUFS available during the Chapter 6 build, though I may have founda way aruond it if I install each package twice, once to its location in /pkgs and once normally, then delete everything outside of /pkgs (with /dev probably being an exception) when done. However, as my university studies keep me busy, I don't actually have time to test this and see if it would work. As for AUFS vs UnionFS, I think AUFS is far superior to UnionFS to the point where in some distros UnionFS isn't even provided (Arch offers AUFS instead of UnionFS). I don't see any features in UnionFS that it isn't in AUFS. Hope this helps, Smartboy -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: UnionFS Package Management
On Tue, Jan 25, 2011 at 04:10:03PM -0600, Mike McCarty wrote: > > I'd like to open discussion of relative merits and demerits. I like > the ability to load and unload packages "live", and give things > a test drive before commiting to them. > Things you might want to consider are "how often do I revert a change of the installed packages ?" and "how long does it take to notice that an upgrade gave a problem?". For me, a series of backups kept for a week or more *mostly* caught the times where I had problems, but two took were more severe and took a lot longer to fix (in the past, a libxml2 vulnerability fix broke something, probably printing, in abiword - re-enabling the vulnerability didn't seem a good alternative; more recently, upgrading beyond gimp-2.6.9 appeared to give problems with *my* usage (process a raw photo using the ufraw plugin, manipulate to fix rotation or perspective distortion, crop to 4:3 format - I no longer had the ratio visible in the gimp). For the latter I ended up ripping out the newer gimp plus a chunk of other stuff. In any case, backups (plus a LiveCD or second system which can mount the affected system and revert it to the backup) seem, to me, to be an essential feature of looking after a system built "my way". I think my own backup scripts are within my current scripts in ~/ken at LFS, but I warn anyone interested that (1.) I use a *lot* of space for my rsync'd backups (typically > 2.5x the data - a version to rsync to (over nfs), then the permanent copies of that) (2.) My scripts probably have all sorts of weird and wonderful bugs that I haven't yet noticed, and (3.) My scripts are definitely *not* safe against memory corruption on the machine holding the backups! [ files get cached - if a cached backup file becomes corrupt, the problem seems to quickly spread through the backups : maybe a reboot might have changed that, but all I'd lost were source tarballs ]. As to using something that isn't in the upstream kernel to handle versioning of the data : it's your data ;) Do you feel lucky ? Well do ya ? In the past, I tried reiserfs3 for test data when development was happening, and sure enough I lost some of that data. That wasn't a problem, but it reinforced my belief that I want a *reliable* filesystem for my data. So, I was slow to move to ext4. If you have a *test* machine, that might be an ideal place to try things out. Just make sure all the *real* data is elsewhere, and verify the contents of backups. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
UnionFS Package Management
Pursuing the subject of package management, I've been considering
the use more than one of the hints. One hint I've explored somewhat
is the Package User hint. I must admit, that while it's simple,
and attractive, I don't like burdening something which isn't intended
to track packages, namely user names, with that task. However, I do
like the additional security provided by having more or less normal
users rather than root doing maintenance.
Another idea I like quite a bit, having used it with similar version
control systems and package managers, is using a fake root build,
that is, installing to a destination other than the final one for
test before final install.
I've been pondering the adavantages of combining the Package User
with the Fake Root, and it appeals to me.
hints/downloads/files/more_control_and_pkg_man.txt
hints/downloads/files/fakeroot.txt
(possibly also crab)
However, after giving some consideration to the UnionFS Hint, I
wonder whether it might not go one step beyond the Fake Root.
hints/downloads/files/pkg_unionfs.txt
I see that it's not quite as simple as the author presents, since it
requires kernel patches and significant modifications to the
initialization process. However, it doesn't look all that difficult,
and fairly straightforward. It does require some "holding one's tongue
just right".
However, I've heard rumors about UnionFS not being quite robust,
and wonder about that. I also note that it hasn't been put in
upstream, nor has its competitor AUFS.
I'd like to open discussion of relative merits and demerits. I like
the ability to load and unload packages "live", and give things
a test drive before commiting to them.
I'd like others who have spent some reasonable amount of time thinking
about using the UnionFS approach to comment, both advantages and
disadvantages, and whether AUFS might be better and why.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Recommended LiveCD?
The mouse works fine if you disable that feature (either the absolute
pointing device or the mouse pointer integration) in VirtualBox,
That feature wasn't documented very well even in VirtualBox's own VM
Settings dialog it isn't completely clear what it does I discovered this by
experimenting with it.
I guess the issues stem from the LFS LiveCD being outdated, if it will be
updated I guess the issues will disappear.
On Thu, Jan 20, 2011 at 9:59 PM, Mike McCarty wrote:
> Someone Somebody wrote:
> > I'm doing it inside VirtualBox and I want a LiveCD that supports
> > VirtualBox's "absoulute pointing device" that is a feature that allows
> you
>
> I'm not familiar with that feature.
>
> > to use mouse pointer integration even without the guest additions
> installed
> > which is quite useful when working from a LiveCD.
> >
> > The LFS LiveCD glitches with this feature (Position desync) so if there
> is a
> > different LiveCD that won't require a lot of modification to build LFS
> with
> > it that this feature works fine with will be quite helpful.
>
> I've used QEMU to build LFS, and didn't experience any problem
> with the mouse.
>
> Mike
> --
> p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
> Oppose globalization and One World Governments like the UN.
> This message made from 100% recycled bits.
> You have found the bank of Larn.
> I speak only for myself, and I am unanimous in that!
> --
> http://linuxfromscratch.org/mailman/listinfo/lfs-support
> FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> Unsubscribe: See the above information page
>
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
