Page 1 of 1


Posted: 26 Nov 2013, 02:48
by edge226
Hello, I plan on trying to make a manjaro/porteus mix. Although a little different than your arch/porteus mix. I am wondering where you started to get the packages ported and working with porteus?

Re: Information

Posted: 27 Nov 2013, 06:16
by stifiling
I 'Arched' one by one, taking the binary pacman out of an Arch Linux installation and running:

Code: Select all

in a terminal.

after it tells which lib is missing...i one by one pulled the missing libs out and placed them in /usr/lib...until it worked. after doing that i used this file in the location /etc/pacman.d/mirrorlist:

Code: Select all

# WARNING! Do not edit this file if you want stable system!
#Server =$repo/os/$arch
Server =$repo/os/$arch
not even sure if that repo is still working, but the necessary adjustments can be made.

i then copied the /etc/pacman.conf file from the Arch Linux installation....and ran

Code: Select all

pacman -S --force -y
and overwrote all the original porteus files, with the Arch Linux ones.

This is a rough draft, but is a base foundation of what i did.

Re: Information

Posted: 27 Nov 2013, 09:12
by edge226
Ah I see. My plan is a little different.

I want to create a system to convert the packages. I do not particularily like how the /changes stuff works. I have had some buggy issues with it in the past. But the first step is to get a working prototype with manjaro packages. I tried switching out the manjaro kernel with one I created. It worked but since it did not have all the other package sets it was not happy. Unfortunately when I load the livecd again it loads the changes from my partition every time. It ended up blowing out my VM and I lost my changes. Shows me for not making a clone before a big change. Also taught me I am going to have to move much of the toolset over before it is going to work properly. I think eliminating the changes stuff would be simple with using pacman and creating a front end wrapper to create the modules. By doing this it gives you more control of how the modules are created and split. You already have tested packages to work with and it is just a matter of converting them. I personally do not like the pure conversion method and want to run a hybrid-package. So for instance you run the install wrapper that downloads the packages needed but does not install. You unxz it and then tar -xvf that. This leaves you with the directory structure of the package. Some of it is left as is and some of it is created into a module. Then all of that is packaged back up and sent back to pacman to install it, Once pacman is done the binaries are then activated from the modules.

What is left as is? Files that may need modification such as config files and things like that.

How can you find out which files may need modification? Well the /changes stuff is good for finding that out, it is in a sense a good debugging tool. Hense why having a porteus-manjaro prototype before the final version which I hope to build up entirely from a manjaro base using some of the porteus tools. Since Manjaro is Arch based. A lot of the development could be cross compatible to getting a really cool modular system for both arch and manjaro (since they are pretty much the same) . That could be done from within the native file structure and with a little work would most likely be easy to setup to be extensible to things like lfs as well.

Why did I Choose manjaro over arch? In a single word that would be stability. Arch has a lot of things you need to watch out for while updating. I personally want a really stable base to go from that has a lot of packages. Cutting edge is good enough for me and means I have less work testing. I've personally had arch updates break my machine. Been using manjaro for a while and that has not happened yet. I've also created my own Live CD on manjaro so I am quite familiar with the build style and how to look up information of what packages a standard manjaro install uses.

This option will probably not be as slim as porteus is, I am not really going for super slim. Quite the opposite, these days I've noticed that instead of customization you are getting different versions of operating systems with a net install for those that want to build their own. While this works well it could be much more functional under a modular system. One of the reasons for me wanting to do this project is that I want to try out some of the newer software out there. some of it takes a much different system configuration than other systems. Sometimes you even have to uninstall down to bare components. An example of this may be that you have installed a bunch of things that rely on your graphics driver. Great with the modular system you can just back all that up and rip it out.

Lets talk about the general structure changes that I would like to implement into my build.
these changes are within the porteus/ directory:
I want to consolidate base into /modules.
I want to change how /modules works so it uses folder names as profile names, with a file within /etc that will allow you to whitelist profiles to load certain xzm sets. This way all xzm's linked with a certain program could have its own profile.
Root Copy is essentially useless as it will by funtionality be the default setup for everything.

Thats all for now. I am sure more will come to me that I want to stick in this post.

Re: Information

Posted: 27 Nov 2013, 12:09
by freestyler
sounds like you want slackware with manjaro packages

Re: Information

Posted: 27 Nov 2013, 23:19
by edge226
freestyler wrote:sounds like you want slackware with manjaro packages
Not really, I am quite happy with how manjaro works. The usefulness and uniqueness of a modularized system is very neat though.

Re: Information

Posted: 27 Nov 2013, 23:48
by ncmprhnsbl
manjaro may be more stable but it still rolls(afaik)
question is, does manjaro have an equivalent to Arch-Rollback-Machine, the culmative repo (Server =$repo/os/$arch)
that effectively freezes the rolling updates. btw is still active...
you can build a system but adding to it later could become problematic..

also maybe building with LinuxLive directly could be easier ... check out latest alphaos
it stays a litte closer to slax in it structure