PSA: Debian needs to be able execute things in /var.

Post #300,305 by static 11/25/08 5:19:21 PM Reply	PSA: Debian needs to be able execute things in /var. It is critical to the way dpkg works. (Unfortunately, it does not tell you this is the problem when things don't work.) Thank you. Wade.
Post #300,307 by folkert 11/25/08 8:53:12 PM Reply	Re: PSA: Debian needs to be able execute things in /var. /var/dpkg/ Has tons of pre, post, rm and inst scripts. Sorry, but this is what /var is for in many modern distributions.
Post #300,308 by static 11/25/08 9:44:38 PM Reply	"modern distro" meets "old-style unix caution" :-) I set /var's options to include noatime and while I was there, added noexec. I mean, you don't put anything executable in /var do you? Well, yes, actually. /var/lib (which has /var/lib/dpkg). Amongst other things, this is The Place to put a range of miscellany that I discovered a few months ago when a MySQL database was installed over in there. I wonder how many other long-time unix people have stumbled on that quirk... Wade.
Post #300,309 by folkert 11/25/08 11:02:10 PM Reply	Re: "modern distro" meets "old-style unix caution" I stumbled on it going from DEC OSF/1 errr Compaq Tru64 errr HP Tru64... HP-UX 9.0x-10.2x and AIX v3.4.x/4.x.x Just like mounting /usr read-only... noooo don't do that now. same thing with /tmp not having executables... many things now "build stuff" in /tmp and run them from there for a second phase of building or compiling or linking Perl is another one to have bad habits built-into it sometimes, but its ok its the LSB now taking full effect of the old guard stuff and making it no longer supported... get the BSDs and other such *NIXs in a tizzy. Personally, I am unhappy about it, but there is justification of it. /var has been changed as from a "state" filesystem to a "status" of many things including DBs and system management scripts with "on install" values saved in them... (like upon mysql removal... should the DBs also be removed?) and other various things. Bleah. Blurring of lines. Hate it... fact of life now, old ways(very tested and tried and trued) are being supplanted by new ways that are much more touchy feely and not always well thought out.
Post #300,310 by static 11/25/08 11:37:43 PM Reply	Looking behind to look ahead. "... and not always well thought out". I think that's the really pointy-bit. The current trend of /var/lib/ falls very neatly in that category, I wot. I still remember the days of "/var/ shouldn't get very big...". I think /var/lib/ happened because it was A Little Change. If a new top directory appeared, say, /app/, within which dpkg put its cache and build areas, MySQL put its database, cvs its repositories, etc etc then it would have been a much more visible change and more discussion would have happened. Perl's bad habits I understand. I'm still sore about a Perl distro masquerading as a CPAN module -- and it's bloody difficult to get a Perl-head to understand what was wrong with that. Wade.
Post #300,319 by folkert 11/26/08 10:43:24 AM Reply	May I remind you that I work for a... Perl based product company, that also uses a Perl based product for CMS (WebGUI) and other things. So, yes I completely understand... we are working a way to make a "Perl Runtime Engine" type of thing to get it out of the hands of the OS to screw it up. Effectively making a /something/prereqs/{bin\|lib\|libexec\|etc\|wth} for "essential runtime" things including MySQL, Perl, Apache, amoung other things. /something/{appname}/{bin\|lib\|etc} for the specific applications and data stores... But again, from a non-dependance on the OS for anything higher than networking/storage/filesystem/(maybe authentication) functions.
Post #300,358 by static 11/26/08 10:26:37 PM Reply	:-)
Post #300,436 by boxley 12/1/08 10:12:19 AM Reply	fully agree with your last sentence

Welcome to IWETHEY!