[9fans] nupas update pushed to sources
just fyi, there were some silly mistakes eliminates, including some with dec64 that might have security implications. (you may wish to apply encodeman patch, too) - erik
Re: [9fans] nupas update
Another view on software managment: http://cr.yp.to/slashpackage/management.html Regards, Jorge-León On 2010-05-16 20:58, Corey wrote: On Sunday 16 May 2010 10:34:53 EBo wrote: Have you tried Sorcery from Source Mage? No, but I'll definitely look into it. Thanks for the pointer. Might also want to check out paludis, a spiritual successor to portage, built from scratch (written in c++), designed with the focused goal of fixing portage's shortcomings: http://paludis.pioto.org/overview/features.html Somewhat related: http://exherbo.org/docs/features.html Sorry no direct experience with these yet - not promoting them, just providing links to info. (I've been using gentoo for a variety of purposes in a variety of roles/capacities and environments for many years now, and it's my linux of choice - the amount of fine-grained control and convenience I've gained via portage has far exceeded the occasional intermittent frustrations)
Re: [9fans] nupas update
On Tue, May 18, 2010 at 2:35 PM, Georg Lehner jorge-pl...@magma.com.ni wrote: Another view on software managment: http://cr.yp.to/slashpackage/management.html My system is very close to that. But I still like the idea that you have as little state as possible, and that package installation be so convenient you don't think about it much. You want to update tex? Well, maybe it's out of date, maybe it isn't, who cares? If the user says reload it, reload it. It only takes a minute or so anyway -- so who cares? It may take a minute figuring out if it is up to date or not with some of the package managers! And they tend to scatter files all over the place; if the package no longer uses them, you have to hunt them down and remove them. But, oh wait, suppose some other package now depends on that file being there? Do you remove it or not? I think in the limit the problem can't be solved. The incredible complexity of the package managers on many systems doesn't really help as much as it seems to cost. ron
Re: [9fans] nupas update
just a comment, the python port includes some hg bits because of my lazyness the thing is that hg isn't just python, it has some c modules that had to be built in in python, so python needs to be recompiled to support hg... so I went the easy way, python already comes with the hg c code. On Mon, May 17, 2010 at 1:09 AM, ron minnich rminn...@gmail.com wrote: On Sun, May 16, 2010 at 6:35 PM, Akshat Kumar aku...@mail.nanosouffle.net wrote: Is `rbind' a recursive bind, that takes care of binding at all depths? Because that's what you'd need in order for the binds to work. And then you shouldn't have any problems. Yes, aki wrote it and yes, I thought it should solve the problems. It did not seem to work. I'll get you a copy. Oh wait look here. http://9grid.net/magic/webls?dir=/aki/src/cmd i sure do miss aki. Can you try the rbind thing and see if I got something wrong? Would be *very* nice to leave the files in the .iso and just bind things. If I can come up with a general set of commands to revert a given package à la history(1)/yesterday(1), I would put a set of those commands in /installed/$i when the package is installed. Then you just pass it to rc and you're golden. I don't think that's good enough. It's fine for standalone packages. But consider hg. It depends on 3 or 4 things. Should you track that stuff too, and not remove python is hg is installed? If python creates 'x', and hg creates 'x', should you remove x if you remove HG? and so on ... This is what makes tracking packages so ugly. It gets ugly fast. I would just as soon mount the .iso's and do binds. ron -- Federico G. Benavento
Re: [9fans] nupas update
On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento benave...@gmail.com wrote: just a comment, the python port includes some hg bits because of my lazyness the thing is that hg isn't just python, it has some c modules that had to be built in in python, so python needs to be recompiled to support hg... so I went the easy way, python already comes with the hg c code. wow. That's crazy of the hg guys but I guess I understand. Anyway, it's not a big problem for people to mix multiple packages into their root, as long as their proto is ok. ron
Re: [9fans] nupas update
On Tue, May 18, 2010 at 7:59 PM, ron minnich rminn...@gmail.com wrote: On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento benave...@gmail.com wrote: just a comment, the python port includes some hg bits because of my lazyness the thing is that hg isn't just python, it has some c modules that had to be built in in python, so python needs to be recompiled to support hg... so I went the easy way, python already comes with the hg c code. wow. That's crazy of the hg guys but I guess I understand. If memory serves, it wasn't done willingly. There were performance problems that the C was used to alleviate. Anyway, it's not a big problem for people to mix multiple packages into their root, as long as their proto is ok. ron
Re: [9fans] nupas update
On Tue, 18 May 2010 20:40:15 -0400 Jorden M jrm8...@gmail.com wrote: On Tue, May 18, 2010 at 7:59 PM, ron minnich rminn...@gmail.com wrote: On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento benave...@gmail.com wrote: just a comment, the python port includes some hg bits because of my lazyness the thing is that hg isn't just python, it has some c modules that had to be built in in python, so python needs to be recompiled to support hg... so I went the easy way, python already comes with the hg c code. wow. That's crazy of the hg guys but I guess I understand. If memory serves, it wasn't done willingly. There were performance problems that the C was used to alleviate. It also doesn't require recompiling/relinking Python on the systems Python and Mercurial are usually used on. (They support dynamic loading of shared libraries.) Robert Ransom
Re: [9fans] nupas update
portage is horrid. i hate it more every time i use it. and it doesn't work. revdep rebuild is proof. it's not clear to me that this is gentoo's fault. linux and gnu together are one heck of a difficult place for a distribution to live. but replicating portage would seem to me to be a big mistake. not only does the plan 9 community lack the resources to maintain 30 different versions of /bin/cp (or whatever), much less portage redux, it will encourage gnu/linux habits, because that's what it's built for. we should build something that encourages a simplier system, a system plan 9 people would really want. - erik
Re: [9fans] nupas update
On 16 May 2010, at 15:03, erik quanstrom wrote: portage is horrid. i hate it more every time i use it. and it doesn't work. revdep rebuild is proof. it's not clear to me that this is gentoo's fault. linux and gnu together are one heck of a difficult place for a distribution to live. but replicating portage would seem to me to be a big mistake. not only does the plan 9 community lack the resources to maintain 30 different versions of /bin/cp (or whatever), much less portage redux, it will encourage gnu/linux habits, because that's what it's built for. we should build something that encourages a simplier system, a system plan 9 people would really want. - erik Indeed, Gnu/Linux is almost unique as an operating system in suffering from an inconsistent base system which, without going into detail, is at the very least a huge abuse of everyone's time. The problem I see here is like this: 1: A consistent base system is extremely desirable. 2: Some parts of the base system sometimes need to be replaced. 3: It is often desirable to be able to safely experiment with replacement basesystem parts. Point 2 raises the questions of which parts, and when. Perhaps upas should be replaced with nupas in the official distribution. Point 3 is the only one which suggests a package manager, but it equally alternatively suggests using a filesystem with history, or perhaps care on the sysadmin's part to archive all files which will be replaced by the new installation. Automated solutions are of course possible, but I don't think there is one which solves conflicts between packages to everyone's satisfaction. I haven't written half what I could have, but I'm in no mood for writing, today. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] nupas update
portage is horrid. i hate it more every time i use it. and it doesn't work. revdep rebuild is proof. it is a lot more dependable than any other package maintenance system I've used on *NIX based systems. The fundamental problem requiring revdep is it's not clear to me that this is gentoo's fault. linux and gnu together are one heck of a difficult place for a distribution to live. but replicating portage would seem to me to be a big mistake. I see that I was not clear. I have no intention of replicating portage, but I DO intend to replicate some of the fundamental functionality. I do not see this as much more than an extension of fgb's contrib or ron's new package installer. If you see otherwise I would love to hear why. not only does the plan 9 community lack the resources to maintain 30 different versions of /bin/cp (or whatever), much less portage redux, it will encourage gnu/linux habits, because that's what it's built for. in practice, there are only two versions which are actively maintained -- the canonical stable version, and the latest experimental. Assuming that the stable version is in fact actually stable, then there is little need to actually maintain older versions, but sometimes it is useful to go back and reconfigure them. Particularly when you have scripts and things which depend on some oddities command line arguments (I'm referring here to the thread regarding standard arguments). Lacking some mechanism to deal with specific versions, just to name one issue, is that you have no easy way to get go back to a known working version when an update breaks something. The situation which prompted this very thread is a case in point. My motivation for wanting, and probably implementing, version controlled builds/runs is to dependently replicating complicated modeling scenarios. we should build something that encourages a simplier system, a system plan 9 people would really want. As I said I was motivated by my portage experience not that I intend to reimplement portage, but even if I did attempt a reimplementation the fact that plan 9 is a much cleaner design, probably 3/4 of the junk is simply not needed. The question is how much of the basic functionality is useful, and what is the most appropriate way to go about implementing it. EBo --
Re: [9fans] nupas update
Indeed, Gnu/Linux is almost unique as an operating system in suffering from an inconsistent base system which, without going into detail, is at the very least a huge abuse of everyone's time. and since plan 9 has a consistent back most of the rigmarole is not necessary, but some is. Before people start arguing that it *will* lead to inconsistancies and gnu/linux'isms it doe not have to. A canonical can be kept separate from any avant garde changes. The problem I see here is like this: 1: A consistent base system is extremely desirable. 2: Some parts of the base system sometimes need to be replaced. 3: It is often desirable to be able to safely experiment with replacement basesystem parts. Point 2 raises the questions of which parts, and when. Perhaps upas should be replaced with nupas in the official distribution. Point 3 is the only one which suggests a package manager, I would debate that point 2 would also benefit, but that is a minor issue. but it equally alternatively suggests using a filesystem with history, or perhaps care on the sysadmin's part to archive all files which will be replaced by the new installation. From personal experience with taking the backup approach, this works fine until you forget about it once, and it also results in a huge number of copies of the system/source laying around. This is less an issue in this day and age of cheap disks, but Automated solutions are of course possible, but I don't think there is one which solves conflicts between packages to everyone's satisfaction. So the question is what functionality are people looking for? EBo --
Re: [9fans] nupas update
On 16 May 2010, at 16:21, EBo wrote: As I said I was motivated by my portage experience not that I intend to reimplement portage, but even if I did attempt a reimplementation the fact that plan 9 is a much cleaner design, probably 3/4 of the junk is simply not needed. The question is how much of the basic functionality is useful, and what is the most appropriate way to go about implementing it. Have you tried Sorcery from Source Mage? I'd say that's Portage without 3/4 of the junk, but it's still quite complex. I may be talking out of my arse but I don't see anything inherent to plan 9 which would simplify a package manager, unless it's the common use of versioning file systems, the use of which may have removed the need for this thread. I'd honestly MUCH rather use a versioning file system than any package manager at all. I dare say a versioning file system is the Right Way and a package manager very much the Wrong Way. On a couple of unix machines I've even started using git to keep revisions in /usr/local. I don't suppose it's entirely brilliant but I've dealt with RPM, I've dealt with Portage, I've dealt with Sorcery (which is very good), I've vaguely sort of coped with dpkg (which always gives me what the hell and ye gods, why feelings), and honestly, even saying Sorcery is very good I'm happier without any package manager. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] nupas update
On Sun, May 16, 2010 at 10:03 AM, erik quanstrom quans...@quanstro.net wrote: portage is horrid. i hate it more every time i use it. and it doesn't work. revdep rebuild is proof. it's not clear to me that this is gentoo's fault. linux and gnu together are one heck of a difficult place for a distribution to live. but replicating portage would seem to me to be a big mistake. not only does the plan 9 community lack the resources to maintain 30 different versions of /bin/cp (or whatever), much less portage redux, it will encourage gnu/linux habits, because that's what it's built for. we should build something that encourages a simplier system, a system plan 9 people would really want. - erik I think some of the ideas behind portage are good, e.g. the ability to handle patches and slim down software via USE flags. That said, Portage is horrible to use, either as someone who just wants to use a package mangler or someone who wants to mangle their software into packages. I think it's probably 60% GNU/GTK/Qt/Shared Libraries'/etc. fault, and 40% Portage being wacky. Portage would have worked better had it targeted Plan 9. So would a lot of things, but we all know the story. That said, Ron's work sounds pretty interesting -- I wonder if he'd consider supporting something like USE-flags or easy patch application, as there are some patches/new versions on sources that would be nice to aggregate and install easily on top of an existing `package'
Re: [9fans] nupas update
On Sun, May 16, 2010 at 11:21 AM, EBo e...@sandien.com wrote: portage is horrid. i hate it more every time i use it. and it doesn't work. revdep rebuild is proof. it is a lot more dependable than any other package maintenance system I've used on *NIX based systems. The fundamental problem requiring revdep is I honestly can't support that. I do like Portage, but it is horribly fragile. The few volunteers that work with it can't keep it from breaking every few months, and when they finally have a fix, it's a long wiki page of instructions, not a simple `ok, everyone update your portage trees for the fix'. Now, I've never seen Portage itself screw up the tree, unlike Apt, which I've seen muck up its own database beyond any repair whatsoever. But still, I've only been nuked by Apt once, and beaten bloody by Portage several times, despite having used Portage much much less than Apt. it's not clear to me that this is gentoo's fault. linux and gnu together are one heck of a difficult place for a distribution to live. but replicating portage would seem to me to be a big mistake. I see that I was not clear. I have no intention of replicating portage, but I DO intend to replicate some of the fundamental functionality. I do not see this as much more than an extension of fgb's contrib or ron's new package installer. If you see otherwise I would love to hear why. not only does the plan 9 community lack the resources to maintain 30 different versions of /bin/cp (or whatever), much less portage redux, it will encourage gnu/linux habits, because that's what it's built for. in practice, there are only two versions which are actively maintained -- the canonical stable version, and the latest experimental. Assuming that the stable version is in fact actually stable, then there is little need to actually maintain older versions, but sometimes it is useful to go back and reconfigure them. Particularly when you have scripts and things which depend on some oddities command line arguments (I'm referring here to the thread regarding standard arguments). Lacking some mechanism to deal with specific versions, just to name one issue, is that you have no easy way to get go back to a known working version when an update breaks something. The situation which prompted this very thread is a case in point. My motivation for wanting, and probably implementing, version controlled builds/runs is to dependently replicating complicated modeling scenarios. we should build something that encourages a simplier system, a system plan 9 people would really want. As I said I was motivated by my portage experience not that I intend to reimplement portage, but even if I did attempt a reimplementation the fact that plan 9 is a much cleaner design, probably 3/4 of the junk is simply not needed. The question is how much of the basic functionality is useful, and what is the most appropriate way to go about implementing it. EBo --
Re: [9fans] nupas update
On 16 May 2010, at 16:37, EBo wrote: From personal experience with taking the backup approach, this works fine until you forget about it once, and it also results in a huge number of copies of the system/source laying around. This is less an issue in this day and age of cheap disks, but but what? I agree making the sysadmin do backups is not the best approach but.. oh man, why has no-one brought this up yet? When the sysadmin forgets he can restore from sources! Look here EBo, go help maintain a Linux distro for a couple of years and THEN come back and tell us your package managers are wonderful swill. I don't think you've even packaged up one piece of software. You can't have if you're promoting package managers so much. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] nupas update
On 16 May 2010, at 16:46, Jorden M wrote: On Sun, May 16, 2010 at 11:21 AM, EBo e...@sandien.com wrote: portage is horrid. i hate it more every time i use it. and it doesn't work. revdep rebuild is proof. it is a lot more dependable than any other package maintenance system I've used on *NIX based systems. The fundamental problem requiring revdep is I honestly can't support that. I do like Portage, but it is horribly fragile. The few volunteers that work with it can't keep it from breaking every few months, and when they finally have a fix, it's a long wiki page of instructions, not a simple `ok, everyone update your portage trees for the fix'. Contrast Sorcery which has multiple well-implemented automated repair systems. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] nupas update
On Sun, May 16, 2010 at 8:53 AM, Ethan Grammatikidis eeke...@fastmail.fm wrote: Look here EBo, go help maintain a Linux distro for a couple of years and THEN come back and tell us your package managers are wonderful swill. I don't think you've even packaged up one piece of software. You can't have if you're promoting package managers so much. As nemo points out, relax. EBo just did a very good thing for all of us: 9vx is part of a distro. I think he's got some credibility at this point :-) ron
Re: [9fans] nupas update
On 16 May 2010, at 17:02, ron minnich wrote: On Sun, May 16, 2010 at 8:53 AM, Ethan Grammatikidis eeke...@fastmail.fm wrote: Look here EBo, go help maintain a Linux distro for a couple of years and THEN come back and tell us your package managers are wonderful swill. I don't think you've even packaged up one piece of software. You can't have if you're promoting package managers so much. As nemo points out, relax. EBo just did a very good thing for all of us: 9vx is part of a distro. I think he's got some credibility at this point :-) ron All right, shutt'n up now, lol. -- Simplicity does not precede complexity, but follows it. -- Alan Perlis
Re: [9fans] nupas update
Look here EBo, go help maintain a Linux distro for a couple of years and THEN come back and tell us your package managers are wonderful swill. I don't think you've even packaged up one piece of software. You can't have if you're promoting package managers so much. well let me see, I think I shared my first portage ebuild in 2004. I have had Sunrise commit privileges for a year or two now, and have posted a few additions, upgrades, and bug fixes along the way. In addition, I am working toward becoming an official Gentoo developer and am negotiating taking over maintenance of the plan9port, 9vx, and inferno ebuilds for Gentoo and getting the ones which are not already in the main tree to be added. And as Ron alluded to below, I just got a 9vx package accepted into the standard packages of TinyCoreLinux (called Tvx). But by your standards this does not sound like enough experience to justify an opinion. The basis of my opinion, however, comes from administrating and software development for systems, networks and clusters over the last 25 years. From a sys admin point of view I often do not have the time to upgrade a system unless I know I can downgrade it if necessary. I have to be able to do this quickly. And no, I do not expect for the upstream maintainers to do this for me and I have 206 ebuilds in my private overlay (I just counted them). As nemo points out, relax. EBo just did a very good thing for all of us: 9vx is part of a distro. I think he's got some credibility at this point :-) Thank you Ron for a call for civility. Reflecting over all this I think that I do not yet know how to communicate in the 9fans' language, and that much of the misunderstandings stem from simple miscommunication. I'll learn with time, and I hope I will not be to annoying in the process. But the couple of times I have seen this kind of vehemence in the past with other code bases it stemmed from software systems which had no package management and difficult build/configure systems. The end result was that new users would either get discouraged and drift off, or they would spend literally hundreds of hours to just get to the point where they can dependably configure, build, and run the code. An interesting consequence of this is that any proposed non-trivial change is met by the old-timers with a resounding DON'T TOUCH IT!!! And there is good reasons for this -- namely that it took some of these people a year or more (quite literally) of training and experience to understand how to maintain the systems. A significant change will cause them to have to go back and learn the new system, and they remember what happened the last two or three times that happened. I have to wonder if the same this applies to the Plan 9 community. If so, the best way to move forward will be to fork the code. EBo --
Re: [9fans] nupas update
Have you tried Sorcery from Source Mage? No, but I'll definitely look into it. Thanks for the pointer. I'd say that's Portage without 3/4 of the junk, but it's still quite complex. I may be talking out of my arse but I don't see anything inherent to plan 9 which would simplify a package manager, unless it's the common use of versioning file systems, the use of which may have removed the need for this thread. Agreed. I do not think that a versioning file system alone goes quite far enough, but it does most of the way.
Re: [9fans] nupas update
Isn't everything great until you see the bad side of it? Stay technical, guys.
Re: [9fans] nupas update
I think some of the ideas behind portage are good, e.g. the ability to handle patches and slim down software via USE flags. this is only necessary if your purpose is to prune overgrown packages. i hope will will solve this problem by not having overgrown pacakges. - erik
Re: [9fans] nupas update
I think some of the ideas behind portage are good, e.g. the ability to handle patches and slim down software via USE flags. this is only necessary if your purpose is to prune overgrown packages. i hope will will solve this problem by not having overgrown pacakges. I see a couple of other applications for use flags besides pruning overgrown packages -- such as should we install source and documentation (yes by default on large systems, no on small embedded systems). Should we strip binaries or compile things for debugging? Install examples? I do not see much call for more than that, but I see those as useful. Another potential use flag or architecture keyword covers if the package can be built, or should build, using 64 bit mode. EBo --
Re: [9fans] nupas update
On Sunday 16 May 2010 10:34:53 EBo wrote: Have you tried Sorcery from Source Mage? No, but I'll definitely look into it. Thanks for the pointer. Might also want to check out paludis, a spiritual successor to portage, built from scratch (written in c++), designed with the focused goal of fixing portage's shortcomings: http://paludis.pioto.org/overview/features.html Somewhat related: http://exherbo.org/docs/features.html Sorry no direct experience with these yet - not promoting them, just providing links to info. (I've been using gentoo for a variety of purposes in a variety of roles/capacities and environments for many years now, and it's my linux of choice - the amount of fine-grained control and convenience I've gained via portage has far exceeded the occasional intermittent frustrations)
Re: [9fans] nupas update
I see a couple of other applications for use flags besides pruning overgrown packages -- such as should we install source and documentation (yes by default on large systems, no on small embedded systems). Should we strip binaries or compile things for debugging? Install examples? I do not see much call for more than that, but I see those as useful. i've tried to make this point several times before. i think it is an error to envision what somebody might want. build want you want. respond to complaints. do not build stuff speculatively. Another potential use flag or architecture keyword covers if the package can be built, or should build, using 64 bit mode. there is no 64 bit kernel. please, no use flags. we can't test what we've got. use flags make the problem go factorial. (gentoo for example doesn't work if you set the profile use flag.) - erik
Re: [9fans] nupas update
i've tried to make this point several times before. i think it is an error to envision what somebody might want. build want you want. respond to complaints. do not build stuff speculatively. Thank you for your clarity. I was hoping to open a discussion and get some feedback so when I do my thing it would likely be more useful. When starting new projects I typically start with a basic idea, then take it to what I call its illogical extreme, and then whittle it back down to the initial project. It is part of how I get a handle on what the scope of work looks like. I guess that approach is in error for 9fans, but it works quite well for me personally. Another potential use flag or architecture keyword covers if the package can be built, or should build, using 64 bit mode. there is no 64 bit kernel. Will there ever be? Or is that even an appropriate question? please, no use flags. we can't test what we've got. use flags make the problem go factorial. (gentoo for example doesn't work if you set the profile use flag.) Now we are getting to the heart of a very important matter. I agree that use flags causes the dependency graph to go factorial -- but pruned to the number of use flags implemented in each ebuild (so it is not factorial to the number of accepted use flags). The situation I am dealing with regards to TinyCoreLinux is that they require that the documentation and source be broken out into separate packages. So, I have currently implemented this as separate portage ebuilds for convenience. But to make this work generally, and for long term maintainability, I have to either implement them as 3*packages or implement this as a doc source use flags and possibly an independent ROOT. The advantage of use flags here is that the source and documentation build is kept together. The disadvantage is that building in use flags increases the complexity somewhat, but is it more than what is saved by including them? I do not know. If I do implement use flags I only see the need for maybe 3 or 4, at least for my uses. I've been bitten in the past by separating parts of a logical package at the package level, but seperate source/docs are required, and I see how this will make things easier when I have time to play with embedded systems again. But this discussion demonstrates my point exactly. If I had not opened the discussion we would not have had the above exchange. I would have simply implemented something with use flags and then when you objected later and I would unlikely be willing to rip it out without really good cause or motivation. Best regards, EBo --
Re: [9fans] nupas update
there is no 64 bit kernel.
Will there ever be? Or is that even an appropriate question?
i think it's a good question but lacking time travel or a working
64-bit kernel, this question is unknowable. :-)
please, no use flags. we can't test what we've got. use
flags make the problem go factorial. (gentoo for example
doesn't work if you set the profile use flag.)
Now we are getting to the heart of a very important matter. I agree that
use flags causes the dependency graph to go factorial -- but pruned to the
number of use flags implemented in each ebuild (so it is not factorial to
the number of accepted use flags).
if each package has only n use flags, then you still have
2^n^m options, where m is the number of packages.
proof: each use flag may be on or off. if we order the use
flags for a package arbitrarly, we can think of them as binary
digits and there would be 2^n possible values. since there
are m packages, we can consider this an m digit number with
each digit taking the value 0 ... 2^n-1.
if they don't all have the same use flags, we can redo this.
if for package k, there are k_n use flags we would have
2^{k_0}2^{k_1} ... =
2^(sum k_i}
which i'll grant isn't factorial. but it's still 2^{sum of use flags
per package}. :-)
i'll give you that this isn't factorial. :-) but on the other hand,
if a package might not be installed at all, that's like another use
flag.
- erik
Re: [9fans] nupas update
I left these questions by Ron to be answered collectively by fellow Plan 9 folks who would try out his new package system. But the conversation deteriorated into a portage: pros and cons debate/seminar. My input follows. On 5/16/10, ron minnich rminn...@gmail.com wrote: It actually works quite well, and probably I should just create a /installed directory, but that was actually an afterthought. What do you recommend? I've already created mine. :) Example: I mount python.iso and do an Aki rbind -ra of /n/python/root / Well ... it just didn't want to work, somehow, although I forget why. I punted at that point and did the dircp, I just ran out of time. Is `rbind' a recursive bind, that takes care of binding at all depths? Because that's what you'd need in order for the binds to work. And then you shouldn't have any problems. So, if we just go with the dircp approach, and copy the files in, what I hear is missing so far: - I don't put the installed info into /installed; should I just go ahead and fix that? What else? Really, the installed paths would just be there as a log of where things went. A straight `dircp' might seem harsh to some, but in my personal setup, I see no problems with such a log and my WORM dumps being taken every day. Then, reverting just means using the history(1) type tools with respect to the log at /installed/$i. That's only a little slower than a bunch of unmount(1) commands, but in totality, keeps a very efficient maintenance system with no hassles. If I can come up with a general set of commands to revert a given package à la history(1)/yesterday(1), I would put a set of those commands in /installed/$i when the package is installed. Then you just pass it to rc and you're golden. Best, ak
Re: [9fans] nupas update
i think it's a good question but lacking time travel or a working
64-bit kernel, this question is unknowable. :-)
;-) After thinking about it I think amd might have been a better example
please, no use flags. we can't test what we've got. use
flags make the problem go factorial. (gentoo for example
doesn't work if you set the profile use flag.)
Now we are getting to the heart of a very important matter. I agree
that
use flags causes the dependency graph to go factorial -- but pruned to
the
number of use flags implemented in each ebuild (so it is not factorial
to
the number of accepted use flags).
if each package has only n use flags, then you still have
2^n^m options, where m is the number of packages.
proof: each use flag may be on or off. if we order the use
flags for a package arbitrarly, we can think of them as binary
digits and there would be 2^n possible values. since there
are m packages, we can consider this an m digit number with
each digit taking the value 0 ... 2^n-1.
if they don't all have the same use flags, we can redo this.
if for package k, there are k_n use flags we would have
2^{k_0}2^{k_1} ... =
2^(sum k_i}
which i'll grant isn't factorial. but it's still 2^{sum of use flags
per package}. :-)
i'll give you that this isn't factorial. :-) but on the other hand,
if a package might not be installed at all, that's like another use
flag.
and without use flags I end up having k*m packages instead of m. So the
question still comes to do I write it to allow 2^n^m possible combinations
and document the two most common scenarios, or write 2*m package variants
and leave it to the interested to populate any of the remaining 2^{k-2}
permutations. I'm still undecided, but I know then kinds of bugs that
creep up when splitting trees like that. (I guess like splitting hairs ;-)
EBo --
Re: [9fans] nupas update
and without use flags I end up having k*m packages instead of m. So the
question still comes to do I write it to allow 2^n^m possible combinations
and document the two most common scenarios, or write 2*m package variants
and leave it to the interested to populate any of the remaining 2^{k-2}
permutations. I'm still undecided, but I know then kinds of bugs that
creep up when splitting trees like that. (I guess like splitting hairs ;-)
at a minimum, ditch the use flags.
these complications are why i decided it
would be easier to just do 9atom.
- erik
Re: [9fans] nupas update
On Sun, May 16, 2010 at 6:35 PM, Akshat Kumar aku...@mail.nanosouffle.net wrote: Is `rbind' a recursive bind, that takes care of binding at all depths? Because that's what you'd need in order for the binds to work. And then you shouldn't have any problems. Yes, aki wrote it and yes, I thought it should solve the problems. It did not seem to work. I'll get you a copy. Oh wait look here. http://9grid.net/magic/webls?dir=/aki/src/cmd i sure do miss aki. Can you try the rbind thing and see if I got something wrong? Would be *very* nice to leave the files in the .iso and just bind things. If I can come up with a general set of commands to revert a given package à la history(1)/yesterday(1), I would put a set of those commands in /installed/$i when the package is installed. Then you just pass it to rc and you're golden. I don't think that's good enough. It's fine for standalone packages. But consider hg. It depends on 3 or 4 things. Should you track that stuff too, and not remove python is hg is installed? If python creates 'x', and hg creates 'x', should you remove x if you remove HG? and so on ... This is what makes tracking packages so ugly. It gets ugly fast. I would just as soon mount the .iso's and do binds. ron
Re: [9fans] nupas update
i sure do miss aki. Can you try the rbind thing and see if I got something wrong? Would be *very* nice to leave the files in the .iso and just bind things. i'm sure if you've followed the trials of the linux union mount system on lwn, you can think of 10 potential reasons, without trying. recursive unions are hard. - erik
Re: [9fans] nupas update
On Sun, May 16, 2010 at 9:19 PM, erik quanstrom quans...@quanstro.net wrote: i'm sure if you've followed the trials of the linux union mount system on lwn, you can think of 10 potential reasons, without trying. recursive unions are hard. ah, but I did over time. I'm not a big fan of the super-complicated unions that those guys keep dreaming up. Aki's program is very simple if you look. ron
Re: [9fans] nupas update
On Sat May 15 19:18:57 EDT 2010, aku...@mail.nanosouffle.net wrote: So, how to resolve this mess and finally install the nupas package? It'd also be nice if somehow files in /mail/lib and other places where installed without hassle (though I'd like to keep some custom configs there). first off, i'm sorry about the problems. i should have tested the nupas-nupas upgrade path more thoroughly. contrib isn't quite the right tool for a direct replacement. sometimes replica gets in its own way. usually when it gets confused, i remove /dist/replica/$x and /dist/replica/client/$x* and often remove any potentially conflicting files. i suppose it would be better to get replica to tell me about conflicts and use -s. i've attached the prototype for the files included in the replica perhaps this will help. you can get a full listing of what + expands to from a listing of /n/contrib/quanstro/root/... - erik386 bin upas addhash aliasmail bayes deliver filter fs imap4d isspam list marshal mbappend ml mlmgr mlowner msgcat msgtok nedmail pop3 qer runq scanmail send smtp smtpd spam spf testscan token unspam vf acme bin 386 Mail mail lib spamhaus validatesender rc bin usenupas splitmbox service !tcp993 tcp143 service.auth tcp993 sys man 1 faces filter mail marshal mlmgr nedmail 4 upasfs 6 mdir rewrite 8 aliasmail pop3 qer scanmail send smtp splitmbox usenupas src cmd faces + upas Mail + alias + bayes + binscripts + common + doc + filterkit + fs mkfile bos.c cache.c fs.c header.c idx.c imap.c mbox.c mdir.c mtree.c plan9.c planb.c pop3.c ref.c remove.c rename.c seg.c strtotm.c dat.h imap4d + marshal + misc + mkfile mkupas ml + ned mkfile nedmail.c
Re: [9fans] nupas update
On Sat, May 15, 2010 at 4:45 PM, erik quanstrom quans...@quanstro.net wrote: sometimes replica gets in its own way. usually when it gets confused, i remove /dist/replica/$x and /dist/replica/client/$x* and often remove any potentially conflicting files. i suppose it would be better to get replica to tell me about conflicts and use -s. Sometimes eh :-) For me, more often than that :-) This type of situation is why I like the concept of packages that never overwrite files in the root file system. To back out you just get rid of the package file, reboot -- fixed. I feel we need improvement on this score. Seems to me with a reasonable set of mount and then binds we could make this type of thing work, and copy files all over / would be a thing of the past. That's what I was trying to do with my attempted package system but failed. Possibly we could put a file in the file system image called autorun.ini that sets things up, i.e. does binds and whatever else is needed? That in essence is what tinycore does ... save for the binds . ron
Re: [9fans] nupas update
This type of situation is why I like the concept of packages that never overwrite files in the root file system. To back out you just get rid of the package file, reboot -- fixed. I feel we need improvement on this score. the ramfs trick will not work if you have a standard plan 9 network with 1 machine. if you used /lib/namespace instead, things would be better. unfortunately since union mounts are not deep, this would be a very difficult thing to construct. i still think it's a mistake to think that not overwriting things is a panacea. the essential problem in this case is that is is difficult (if not impossible) to test the tuple (original version upgrade version, base system). - erik
Re: [9fans] nupas update
By the way, Ron, in order to sort this mess out, with the help of Federico, I essentially carried out the operations in the install script of your new package system. I notice you don't keep a list of installed file paths in /installed/$i -- is that something you've already tried, for maintaining removal info and what not? Perhaps the file itself can contain the binds and mounts specific to its going about its own removal. Best, ak On 5/16/10, ron minnich rminn...@gmail.com wrote: On Sat, May 15, 2010 at 4:45 PM, erik quanstrom quans...@quanstro.net wrote: sometimes replica gets in its own way. usually when it gets confused, i remove /dist/replica/$x and /dist/replica/client/$x* and often remove any potentially conflicting files. i suppose it would be better to get replica to tell me about conflicts and use -s. Sometimes eh :-) For me, more often than that :-) This type of situation is why I like the concept of packages that never overwrite files in the root file system. To back out you just get rid of the package file, reboot -- fixed. I feel we need improvement on this score. Seems to me with a reasonable set of mount and then binds we could make this type of thing work, and copy files all over / would be a thing of the past. That's what I was trying to do with my attempted package system but failed. Possibly we could put a file in the file system image called autorun.ini that sets things up, i.e. does binds and whatever else is needed? That in essence is what tinycore does ... save for the binds . ron
Re: [9fans] nupas update
On Sat, May 15, 2010 at 9:28 PM, Akshat Kumar aku...@mail.nanosouffle.net wrote: I notice you don't keep a list of installed file paths in /installed/$i I do, but the intent is that you bind -a package /, and the 'installed' in there has the files. I have this allergy to dropping stuff into / :-) Perhaps the file itself can contain the binds and mounts specific to its going about its own removal. Yes, this is a good idea. I have not taken this idea as far as it can go; consider it a preliminary step and I welcome the kinds of improvements that you smart guys are proposing! thanks ron
Re: [9fans] nupas update
I do, but the intent is that you bind -a package /, and the 'installed' in there has the files. that won't work unless the differences are at the same level as the bind, in this case /. - erik
Re: [9fans] nupas update
On 5/16/10, ron minnich rminn...@gmail.com wrote: On Sat, May 15, 2010 at 9:28 PM, Akshat Kumar aku...@mail.nanosouffle.net wrote: I notice you don't keep a list of installed file paths in /installed/$i I do, but the intent is that you bind -a package /, and the 'installed' in there has the files. I have this allergy to dropping stuff into / :-) However, I don't see such binds going on in your install script at http://9grid.net/rminnich/src/package-tools/install - instead, there is a straight dircp. So, is this a thing you're developing personally? Perhaps the file itself can contain the binds and mounts specific to its going about its own removal. In consideration of your bind idea, I think you can go a little further: the /installed/$i file on disk can contain info for binding the installed package onto /. Then, the /installed/$i file resulting from the binds can contain removal procedures. I'm not sure what would be the most comfortable from a use perspective, but it's an idea Best, ak
Re: [9fans] nupas update
On Sat, May 15, 2010 at 9:57 PM, Akshat Kumar aku...@mail.nanosouffle.net wrote: http://9grid.net/rminnich/src/package-tools/install no, it's not there, as I am not yet satisified with the right way to do this. - instead, there is a straight dircp. yes. So, is this a thing you're developing personally? no, what you see is what I've got right now. It actually works quite well, and probably I should just create a /installed directory, but that was actually an afterthought. What do you recommend? In consideration of your bind idea, remember: unimplemented because I could not quite get it to work. Example: I mount python.iso and do an Aki rbind -ra of /n/python/root / Well ... it just didn't want to work, somehow, although I forget why. I punted at that point and did the dircp, I just ran out of time. I think you can go a little further: the /installed/$i file on disk can contain info for binding the installed package onto /. Then, the /installed/$i file resulting from the binds can contain removal procedures. I'm not sure what would be the most comfortable from a use perspective, but it's an idea I think it's worth trying out. I just don't have the time right now. So, if we just go with the dircp approach, and copy the files in, what I hear is missing so far: - I don't put the installed info into /installed; should I just go ahead and fix that? What else? ron
[9fans] nupas update
i've pushed an update of my nupas contrib package to sources. imap successful in use with apple mail (snow leper, too), iphone, outlook, opera, ff, upas/fs. note on installing: as devon pointed out, installation is still a big pain. 1. move /sys/src/nupas - onupas 2. contrib/install quanstro/nupas if you want to go cold turkey nupas, then a. mv /386/bin/upas /386/bin/oupas b. mv /386/bin/nupas /386/bin/upas c. (opt)edit top-level mkfile to install in /386/bin/nupas. if you want to hedge your bets a. add usenupas to your profile b. edit cpurc as you see fit to use nupas binaries. cavet: i have not had a chance to retest the contrib package. as always, feedback welcome. - erik
Re: [9fans] nupas update
On Wed, Sep 2, 2009 at 7:16 PM, erik quanstrom quans...@quanstro.netwrote: i've pushed an update of my nupas contrib package to sources. imap successful in use with apple mail (snow leper, too), iphone, outlook, opera, ff, upas/fs. note on installing: as devon pointed out, installation is still a big pain. 1. move /sys/src/nupas - onupas 2. contrib/install quanstro/nupas if you want to go cold turkey nupas, then a. mv /386/bin/upas /386/bin/oupas b. mv /386/bin/nupas /386/bin/upas c. (opt)edit top-level mkfile to install in /386/bin/nupas. if you want to hedge your bets a. add usenupas to your profile b. edit cpurc as you see fit to use nupas binaries. cavet: i have not had a chance to retest the contrib package. as always, feedback welcome. So when you say that it works with Snow Leopard too, are you meaning that this works *on* snow leopard with something like FUSE 9p via plan 9 from user space? Just curious. - erik
Re: [9fans] nupas update
So when you say that it works with Snow Leopard too, are you meaning that this works *on* snow leopard with something like FUSE 9p via plan 9 from user space? imap4d and upas/fs are running on a regular plan 9 install. apple mail is running as normal. there is no 9p required on the mac. while i'm sure that the p9p client stuff would work with nupas imap4d, it would take work to port the servers. - erik
[9fans] nupas update
i just pushed an update of nupas to sources. it fixes a few bugs, including - a recursive sync loop has been eliminated.. (this has been the source of some mystery crashes) - dualing upas/fs operating on the same mbox no longer miss deletions. the fix is less than elegant. also on 27 jul, a crash with truncated mime sections was fixed. it might be that there is still a bug in imap that caused the original problem. but it could also be due to the recursive sync loop. thanks for the bug reports! - erik
[9fans] nupas update
i pushed a new version of nupas out to /n/sources/contrib/quanstro/src/nupas. the upas/fs and delivery system have been significantly hardened since last time i mentioned it. i pushed man pages for mdir and splitmbox (as well as the splitmbox script) to the bits directory. nupas still installs itself to /$objtype/bin/nupas so you will need to modify mknupas to install it as the default mail system. imap4d has come around quite nicely and seems to be largely agreeing with apple mail and firefox. limiting testing with outlook and opera has been successful. mail boxes with spaces, as silly email clients are wont to create are supported even with fs not supporting spaces in file names. (my apologies.) (most of the problem was with the LIST and LSUB commands which i found never worked correctly for some common queries. e.g. lsub inbox*.) while migration is not complete, nupas does have users with mailboxes with as many as 8,500 messages and as large as 1GB. questions and comments welcome. - erik
