[9fans] nupas update

[9fans] nupas update

[erik quanstrom]

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

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

On Wed, Sep 2, 2009 at 7:16 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 1609 bytes --]

Re: [9fans] nupas update

[erik quanstrom]

> 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

Re: [9fans] nupas update

[Akshat Kumar]

I have nupas from a long time back and recently
decided to run

  contrib/install quanstro/nupas

However, it seems that the nupas package has
since been moved from nupas to overwrite the base
upas, along with base files in /sys/man, other src
directories (faces, etc.) and some files in /mail/lib.
In short, my upas install is now botched with a mix
of stuff from quanstro/nupas that could be updated,
and a lot of missing stuff. I don't have a problem with
overwriting completely, since nupas has been working
so well for me for so long, but now I'm left in the cold
with no proper upas or nupas (the old /386/bin/nupas
was also removed during the pull).

As such, I tried a subsequent pull with the -s flag to
list directories I would like updated, but pull thinks
everything is up to date, so it makes no action. Then
I tried my hand at

  contrib/remove quanstro/nupas | rc
  contrib/install quanstro/nupas

but of course that brings me back to where I was with
the first contrib/pull. And of course a subsequent pull
doesn't do anything, as described above.

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).


Thanks,
ak

On Wed, Sep 2, 2009 at 7:16 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> 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

[erik quanstrom]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Sat May 15 19:18:57 EDT 2010, akumar@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/...

- erik

[-- Attachment #2: nupas --]
[-- Type: text/plain, Size: 1410 bytes --]

386
	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
				pop3
					+
				q
					+
				scanmail
					+
				send
					+
				smtp
					+
				spf
					+
				vf
					+

Re: [9fans] nupas update

[ron minnich]

On Sat, May 15, 2010 at 4:45 PM, erik quanstrom <quanstro@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

[erik quanstrom]

> 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

[Akshat Kumar]

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 <rminnich@gmail.com> wrote:
> On Sat, May 15, 2010 at 4:45 PM, erik quanstrom <quanstro@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

[ron minnich]

On Sat, May 15, 2010 at 9:28 PM, Akshat Kumar
<akumar@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

[erik quanstrom]

> 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

[ron minnich]

On Sat, May 15, 2010 at 9:39 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> 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 /.

I already do that today :-)

term% bind -a package /
term% ls /installed
/installed/bz2
/installed/hg
/installed/openssl
/installed/python
/installed/tex
/installed/z
term%

thanks

ron

Re: [9fans] nupas update

[Akshat Kumar]

On 5/16/10, ron minnich <rminnich@gmail.com> wrote:
> On Sat, May 15, 2010 at 9:28 PM, Akshat Kumar
> <akumar@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

[ron minnich]

On Sat, May 15, 2010 at 9:57 PM, Akshat Kumar
<akumar@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

Re: [9fans] nupas update

[EBo]

>>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?

I too have been interested in this, but I come at it from my experience
with portage.  The following are things that I would like to either see
added or would like to try to contribute as time allows:

* versioning support and control - helpful for determining exactly what
software is being run, and facilitates developers being able to configure
machines similarly by providing the installed package list (called world in
portage parlance).

* ability to specify stable and experimental versions of a program - so we
have dependable installs and still can support the bleeding edge

* package masking and unmasking - sometimes a particular package is
determined to be buggy on a particular system or configuration and we need
to be able to mark it as "do not do this"

* live vs. predefined versioning - by convention packages in portage are
based off of specified versions.  They do provide a mechanism for "live"
updates.  This is done so that pulling the source tree does not roach some
part of the system.

* dependency specification - package developers know exactly what
dependencies are required, and should be able to specificity what versions
of libraries, etc., should or should not be built against.

* patch ability - adding the ability to specify specific patches in the
package system facilitates maintenance and specialty hardware
experimentation.

* checksum on all associated files - security, but also assures that I did
not do a boneheaded move and modified something.

* package associated installed file list - each file on the system is
associated with a single package which protects it for being hammered by
another package, and this facilitates dependable uninstall operations.

* auxiliary trees - called overlays in portage, allows different forks to
maintain their own changes separately (this would be particularly useful
for migrating between 9atom and the canonical source tree).

* cross platform and alt root support - this allows us to build for
different target platforms which might be unrealistic to have an entire
installed platform like the styx-on-a-brik.

As a note, the above were some of the motivations behind my Gentoo based
GSoC application (I already have a list of over 30 points to consider in my
notes).  All of the above functionality is available in portage, but
portage is written in python; which is to steep a requirement for a useful
pla9 build tool IMHO.  Hence my plans to writing it in rc if I end up
developing this functionality.  Also, I only see a small portion of the
above as being required for my current modeling work (namely versioning,
dependencies, and cuecksums), but I have found the rest of the
functionality unbelievably useful from supporting embedded systems to
beowulf clusters.

  EBo --

Re: [9fans] nupas update

[erik quanstrom]

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

[Ethan Grammatikidis]

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

[EBo]

> 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

[Ethan Grammatikidis]

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

[ron minnich]

On Sun, May 16, 2010 at 8:53 AM, Ethan Grammatikidis
<eekee57@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

[Ethan Grammatikidis]

On 16 May 2010, at 17:02, ron minnich wrote:

> On Sun, May 16, 2010 at 8:53 AM, Ethan Grammatikidis
> <eekee57@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

[EBo]

>> 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

[EBo]

> 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

[Ethan Grammatikidis]

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

[EBo]

> 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

[hiro]

Isn't everything great until you see the bad side of it?
Stay technical, guys.

Re: [9fans] nupas update

[Corey]

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

[EBo]

> 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

Thanks for the pointer.  I am aware of paludis, but did not consider its
use because lack of C++ support on Plan 9.  It might be a better reference
than portage though.

> Sorry no direct experience with these yet - not promoting
> them, just providing links to info.

fair enough, and thanks.

> (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)

my feelings exactly.


  EBo --

Re: [9fans] nupas update

[Georg Lehner]

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

[ron minnich]

On Tue, May 18, 2010 at 2:35 PM, Georg Lehner <jorge-plan9@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

[Jorden M]

On Sun, May 16, 2010 at 11:21 AM, EBo <ebo@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

[Ethan Grammatikidis]

On 16 May 2010, at 16:46, Jorden M wrote:

> On Sun, May 16, 2010 at 11:21 AM, EBo <ebo@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

[Jorden M]

On Sun, May 16, 2010 at 10:03 AM, erik quanstrom <quanstro@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

[erik quanstrom]

> 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

[EBo]

>> 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

[erik quanstrom]

> 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

[EBo]

> 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

[erik quanstrom]

> > 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

[EBo]

> 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

[erik quanstrom]

> 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

[Akshat Kumar]

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 <rminnich@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

[ron minnich]

On Sun, May 16, 2010 at 6:35 PM, Akshat Kumar
<akumar@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

[erik quanstrom]

> 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

[ron minnich]

On Sun, May 16, 2010 at 9:19 PM, erik quanstrom <quanstro@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

[Federico G. Benavento]

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 <rminnich@gmail.com> wrote:
> On Sun, May 16, 2010 at 6:35 PM, Akshat Kumar
> <akumar@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

[ron minnich]

On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento
<benavento@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

[Jorden M]

On Tue, May 18, 2010 at 7:59 PM, ron minnich <rminnich@gmail.com> wrote:
> On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento
> <benavento@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

[Robert Ransom]

On Tue, 18 May 2010 20:40:15 -0400
Jorden M <jrm8005@gmail.com> wrote:

> On Tue, May 18, 2010 at 7:59 PM, ron minnich <rminnich@gmail.com> wrote:
> > On Tue, May 18, 2010 at 4:50 PM, Federico G. Benavento
> > <benavento@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

[9fans] nupas update

[erik quanstrom]

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

[erik quanstrom]

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