wiak wrote:With great respect s243a, I can't help but wonder from your many posts about your attempted woof-next developments if you have placed yourself in some very deep water? Clearly from what your write there are some great issues/complexities involved, including pkg issues and device files missing and so on.
Yes but at the same time you can learn a lot by reviewing someone else's code. I also think that woof-next can evolve beyond a distribution builder. I think that it can become a full fledged interpreter that can also be used as a package manager.
That is the trouble with taking over someone elses complex system many years after it was originally written too I feel. Personally I wouldn't myself try.
I understand this but I was looking at woof-next because it has fewer lines of code than woof-CE. It also lets me learn about woof-CE because there are components of woof-CE incorporated into woof-Next.
My main point is that, you are clearly trying your very best to get a good outcome here and it certainly would be great if you manage, but please don't be afraid to ever throw in the towel if the issues you come across proves to be insurmountable (which can sometimes be the case).
This is a fair comment but I know that woof-next can successfully build a debian or slackware distribution. Therefore, if the goal is only to build slackware and debian based distributions than it isn't that far behind woof-CE...albiet with older code.
Jamesbond claims it can also build fatdog like distributions but i need to see more info on this.
I do question though whether or not woof-next can "as is" build a devaun based distro. It appears from some peoples report that it has but due to some issues that I've encounter, I am somewhat skeptical...the device file issue being the top issue on my the list of why I'm skeptical about whether or not the official woof-next can produce a devaun distro.
P.S. I was actually able to boot into a tinycore like system using woof-next but it wasn't really tinycore. It was puppy calling tinycore's init scripts. I also (regarding devaun builds) got past rc.sysinit to where qemu was looking for plogin...so it is possible that I broke some things along the way but hopefully in the end this will create a better system.
It's not worth the stress and effort sometimes and you were doing very well with your 64-bit TazPup dev work and I miss seeing you completing that.
Thanks for the compliment
I wasn't aware there was much interest in TazPup64 but I have been using it daily. I do think that TazPup64 is a good project because most newer 64bit puppies (in my opinion) don't preform well on older machines. I do know that this is somewhat of a hardware specific issue because I know that some people do have old hardware that runs newer 64 bit pupps well.
I didn't want to say anything because of course it would be great if woof-next could be resurrected as an alternative Puppy build system, and maybe you are close (I don't know) - just hoping you take stock and make sure you don't tire yourself out on anything that proves impossible.
I don't think it's impossible and I do think that I'll learn a lot.
I am particularly concerned if it is the case that pkg has any issues that prevent your success - any package manager, as you know, is a complex beast and despite pkg being a much-needed kind of commandline driven package manager for Puppy, I don't think it has been given a great deal of community testing as yet (of course you are helping with that). That could prove to be a road-block, for now, that you cannot reasonably pass?
Woof-Next does have the option of using the native package manager (or even the official puppy package manager). To me this is unsatisfying because in my opinion dpkg/apt complains too much if things aren't perfect and petget doesn't support the command line.
I think that if I create a distro (/derivative distro) that is functional and uses Sc0tmann's pkg as the package manager then this will create interest in the distro and help Sc0tmann's package manger progress.
I don't think that pkg has to work perfectly in the first release of the distro and having something that works well enough will be enough to help spur further development/testing of pkg.
So if you do hit any such roadblock, which it is unreasonable for you to shift yourself, please do not be afraid to freeze your woof-next project if you have to. 64-bit TazPup also beckons and results there were looking very positive.
wiak
I'm glad you think so. My intent wasn't to completely freeze TazPup64 but I did want to get woof-next far enough a long so that I could better split my time. On my upstairs floor I have a 64bit computer running TazPup64, on the lower floor I have a 32bit computer running dpup strech. So in theory being able to develop woof-next on the 32 bit computer gives me more development time.
The problem of course is the amount of mental energy that it takes to be able to balance two complex projects becasue some times troubleshooting requires a large mental roadmap of where in the code various things are done and not everyone can do this kind of multitasking.
p.s. 1 I hope that my error reports of either pkg or woof-next don't misrepresent these two systems. As with any system, user error is always a possibility.
That said, sometimes it is essential to use system in the way that the author didn't intend in order for the system to progress.
p.s. 2 Development on woof-next may help me with TazPup64 because both systems use components of woof-CE, so the resulting knowledge gained is likely helpful. Also sometimes scripts developed on one system can be reused on another. Also I may create a config file to build a TazPup64 like system on woof-next. If I do so then there will be more cross-fertilization between what I do on woof-next vs TazPup64.
ps. 3: Some issues that I'm experience might be due to me using a different puppycore (aka rootfs-skeleton) than provided by jamesbond. I'm doing this so that I'm using newer woof-CE code and also because greater modularity is required to make woof-next more flexible in the type of systems that it can build.