So, we're working with an embedded device. This device, depending can use a tiny rootfs depending. In effect, the apt cache "problem" is two fold.
First, writing to media, which in the case of our board here is flash. Sure, maybe if you're using apt you're installing something, which does write to flash. But why compound that by also writing the cache to flash too ? Second, is size. the apt cache can eat up a lot of space, if you let it. Sometimes, this is not so important, other times it is. I'll let you use your imagination here. It has been a long, long time since I've seen really bad "apt errors" - e.g. corrupting the rootfs somehow, or broken packages etc. But it did used to happen, which is why we can read about, or talk to people who swear by aptitude. Now days, I'd go so far to say that this is a non issue. However . . . what you will run into is APT complaining about your repo(s) not being in sync, and the error message given is not always obvious. I can not give you the exact text of the errors I've seen in the past, but they typicaly go something like "E: unable to lock . . ." or "E: unable to find . . .". Sometimes these error might even confuse a user into believing that a given package does not exist . . . which is the main reason why I suggest just to use apt-get update *always*. It's less pain for them, and others when trying to help with various problems. On Mon, Oct 19, 2015 at 4:08 PM, Rick Mann <rm...@latencyzero.com> wrote: > My problem is that I don't understand how putting the apt cache in RAM is > beneficial if what you're trying to do is avoid flash writes. If you're > updating the cache, then you're also intending to install or upgrade > software, which will write to flash. If it's in RAM and not persisted, > forcing you to do an update each time you do an install or upgrade, how > does this prevent writing to flash? > > So, either I'm not understanding the intent, or I'm not understanding how > apt works. > > If instead it's best practice to always update before installing, then why > not have apt-get install just update the cache each time? > > All I see is no benefit but the potential for error (e.g., not getting the > version of the package you thought you were getting, or in the best case, > confusing errors due to conflicts). I don't see how putting the cache in > RAM helps anyone, novice or expert. > > Now, if the intent is just to speed up accesses, rather than reduce flash > writes, then loading the cache at boot from a store on disk, and accessing > the cache in ram, makes sense. However, it seems that in this case, apt-get > update should update both the cache and the on-disk store. > > In all this, I'm questioning the wisdom of the apt authors, not you or > Robert or anyone else on this list. > > > > On Oct 19, 2015, at 15:53 , William Hermans <yyrk...@gmail.com> wrote: > > > > I'm not attacking you, William, I'm asking for clarification. It doesn't > make any sense to me that apt-get update wouldn't write its results to disk. > > > > You don't need to apt-get update all the time, if it writes its results > to disk. But if it doesn't, and you forget to next time you apt-get > install, you run the risk of downgrading something you have installed (or > otherwise corrupting it), don't you? > > > > Not attacking you either Rick, but here is the point. The official > images come with this enabled. So whether you, I, or anyone else cares, > it's already in there. The apt sources cache is either completely in RAM, > with a default cache set at build time, or it is a minimal gzipped archive. > Technically, no you do not *have* to run apt-get update _every_single_time_ > you go to use APT, but generally it is a good idea. All it takes is an > update in one repo or another( depending ), and apt-get install, apt-get > upgrade, etc will fail, barfing out some message similar to E: could not > locate x.y.z. > > > > Either way, the blog was meant for people who are new to Beaglebone, or > Linux development in general. If you're good with Debian(Linux), you > probably do not need my guides. > > > > Passed that, many people are worried about writing to flash too much, > and I'm one of them. I've been using an A5A for gaining on 3 years now, > with no flash problems, and that includes the Sony class 10 SDHC card that > we bought for it back then. As it is, I make enough mistakes of writing to > flash, accidentally, to worry about all the compiling, apt-get installing, > etc. This is also why one of my first blog posts was on how to setup NFS > shares, and NFS root for the Beaglebone. Not to mention I compile often, > and a lot. Granted, compiling over an NFS share *is* slower, but I can live > with that. But it's also why I have a cross system for the larger projects, > or is why I wrote another blog on how to setup a USB rootfs . . . > > > > I was also a bit "quick" this morning . . . which is how I normally am > for the first few hours after waking up. Still, if I write something in my > blog posts, and you do not get it. Don't worry so much about it. It was > probably not meant for you, or other advanced users. It was meant to keep > people, who are new out of "trouble", with minimal explanation required > from me. > > > > On Mon, Oct 19, 2015 at 2:13 PM, Robert Nelson <robertcnel...@gmail.com> > wrote: > > On Mon, Oct 19, 2015 at 4:10 PM, Rick Mann <rm...@latencyzero.com> > wrote: > > > I'm not attacking you, William, I'm asking for clarification. It > doesn't make any sense to me that apt-get update wouldn't write its results > to disk. > > > > > > You don't need to apt-get update all the time, if it writes its > results to disk. But if it doesn't, and you forget to next time you apt-get > install, you run the risk of downgrading something you have installed (or > otherwise corrupting it), don't you? > > > > It's really hard to down-grade in debian, and any cache corruption > > should stop dpkg from installing a *.deb package.. > > > > Regards, > > > > -- > > Robert Nelson > > https://rcn-ee.com/ > > > > -- > > For more options, visit http://beagleboard.org/discuss > > --- > > You received this message because you are subscribed to the Google > Groups "BeagleBoard" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to beagleboard+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > For more options, visit http://beagleboard.org/discuss > > --- > > You received this message because you are subscribed to the Google > Groups "BeagleBoard" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to beagleboard+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > -- > Rick Mann > rm...@latencyzero.com > > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
