Absolutely not anyone with any great ideas, whether they're from gentoo, arch, debian, ubuntu etc.....i'm all ears. This porteus-arch system, has no default base to give full credit to, of where it came from...it's really a mixture of a lotta different ideas, from a lotta different places. Porteus, Arch, Puppy, and the ideas from the user simargl from the puppy linux forum holding the most weight.francois wrote:I hope you do not count on archlinux experts only.
Not starting with the original, stock Porteus....but starting with this porteus-arch. When i say start clean/fresh...i'm meaning using this system, but without a .dat save file that u've already started installing apps in. If you want to create an xzm module, it's better to start new with this porteus-arch system (if this is the system u're interested in using, they won't work with the original Porteus). The reason for this, rather than one halfway set up is because if say a wine dependecy is already installed in the .dat file from some other app you installed....when you make the .xzm file...it will pull down only the dependecies that aren't already installed. So if you already have a dependecy installed in the .dat file, from some other app you installed which uses that dependecy as well....you more than likely won't know, and will make your .xzm module, without that dependency. If that happens, and you decide later you want to start with a new .dat file....you may wonder why wine isn't working correctly. and the reason would be because you got rid of a required dependency when you got rid of the previous .dat save file. This is why if you want to make .xzm modules, it's best to do it on a fresh porteus-arch installation...so that they will have all the required depencencies and will always work, even if you start over with a new .dat save file.francois wrote:From this last post, I understand that I should create modules as in porteus stock ALWAYS FRESH mode. That is, with the basic system that could be downloaded, that I install package after package, series of packages with pacman, transform them into porteus-archlinux modules and get rid of the traces of these packages in the folder structure.
yes, all i'd really need to know is the name of the package you were installing when you got the file conflict. and it should happen to me as well when i try to install the same app, then i'll know exactly which files to remove from this base porteus-arch installation.francois wrote:1) if a package has to be forced to be installed, you would appreciate that we report that it had to be forced.
*Here, would you like the output of the pacman -S the-package-to-be installed?
** Yet I had to force xorg-xscreensaver, kdegame-kigo, kdegame-kmahjong, domination (game).
2) does it makes any difference for you if I work thru many packages at once, or if I work package by package? (i.e. separately, gimp, openoffice, xscreensaver, ...)
it doesn't matter if you do package by package or not, pacman should tell you exactly which package it is that's trying to install, but won't because of a file conflict. so even if you used pacman to install 4 apps at the same time ex. 'pacman -S guake pcmanfm leafpad dolphin'......pacman will tell you in the terminal which package it is exactly that's causing the conflict.
As we can see in fanthom's post, he was installing kaffeine, but a couple of the dependecies for kaffeine caused the conflict:
Code: Select all
libutempter: /usr/lib/libutempter.so exists in filesystem
libutempter: /usr/lib/libutempter.so.0 exists in filesystem
libutempter: /usr/lib/utempter/utempter exists in filesystem
sysfsutils: /usr/bin/dlist_test exists in filesystem
sysfsutils: /usr/bin/get_device exists in filesystem
sysfsutils: /usr/bin/get_driver exists in filesystem
sysfsutils: /usr/bin/get_module exists in filesystem
sysfsutils: /usr/bin/systool exists in filesystem
sysfsutils: /usr/lib/libsysfs.so exists in filesystem