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
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
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
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,
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
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
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
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
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
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
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.
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
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
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
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
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 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
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
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
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
Isn't everything great until you see the bad side of it?
Stay technical, guys.
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
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
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
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
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
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
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
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.
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}
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
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.
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
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
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
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
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
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 /
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
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
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
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
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
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.
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
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
46 matches
Mail list logo
