Update method of choice: Porteus vs Arch way?

Arch based Porteus community project
datruche
Black ninja
Black ninja
Posts: 95
Joined: 20 Sep 2015, 21:02
Distribution: Arch, Porteus-Nemesis 3.5
Location: London > . < Paris

Update method of choice: Porteus vs Arch way?

Post#1 by datruche » 31 Jan 2016, 15:15

After one succesfuly installs the latest Nemesis pre-release he'll want to update his new system. Same goes after you swith from, say, Nemesis 3.4 to 3.5.

Which he can achieve via either of the two commands:
Porteus way

Code: Select all

# setup-pman && pman -Syu
or the Arch way

Code: Select all

# setup-pman && pacman -Syu
There's also pamac the graphic wrapper to pacman (which I dunno about as I don't use it) in the equation.

Whatever command he chooses he'll be presented with a list of updates; and that one can be impacting upon the first time, e.g. as of today:

Code: Select all

$ sudo pman -Su
[sudo] password for kozaki: 
error: duplicated database entry 'acpid'
error: duplicated database entry 'libsecret'
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
warning: dependency cycle detected:
warning: eudev will be installed before its eudev-systemdcompat dependency

Packages (76) acpid-2.0.26-1  adwaita-icon-theme-3.18.0-1  avahi-0.6.32rc-4
              ca-certificates-mozilla-3.21-1  cdrtools-3.02a05-1  consolekit-1.0.1-2
              dcadec-0.2.0-1  device-mapper-2.02.138-1  dhcpcd-6.10.0-1  elfutils-0.165-1
              eudev-3.1.5-3  eudev-systemdcompat-228-1  ffmpeg-1:2.8.5-2  fuse-2.9.5-1
              gmp-6.1.0-3  gnupg-2.1.10-3  gnutls-3.4.8-1  graphite-1:1.3.5-1
              gsm-1.0.14-1  gtk-update-icon-cache-3.18.6-2  gtk3-3.18.6-2
              harfbuzz-1.1.3-1  inxi-2.2.32-1  iso-codes-3.64-1  libass-0.13.1-1
              libbsd-0.8.1-1  libdrm-2.4.66-1  libelf-0.165-1  libevdev-1.4.6-1
              libldap-2.4.43-1  libnm-glib-1.0.10-2  libnotify-0.7.6-2  libpulse-8.0-1
              libsecret-0.18.4-1  libteam-1.23-1  libwbclient-4.3.4-1  libwebp-0.5.0-1
              llvm-libs-3.7.1-1  mesa-11.1.1-1  mhwd-db-0.5.6-9  mpfr-3.1.3.p5-1
              nano-2.5.1-1  network-manager-applet-1.0.10-1
              networkmanager-consolekit-1.0.10-2  networkmanager-openvpn-1.0.9-1
              nm-connection-editor-1.0.10-1  nspr-4.11-1  nss-3.21-1  ntp-4.2.8.p5-1
              openrc-0.20.4-1  openssh-7.1p2-1  opus-1.1.2-1  p11-kit-0.23.2-1
              pacman-mirrorlist-20160108-1  pamac-2.4.3-5  pciutils-3.4.0-1  perl-5.22.1-1
              python-packaging-16.0-1  python-pyparsing-2.0.7-1
              python-setuptools-1:19.5-1  python-six-1.10.0-1  rp-pppoe-3.12-1
              rsync-3.1.2-1  rtmpdump-1:2.4.r96.fa8646d-1  smbclient-4.3.4-1
              sqlite-3.10.2-1  vim-7.4.1089-1  vim-runtime-7.4.1089-1  vte-common-0.42.1-2
              vte3-0.42.1-2  wpa_supplicant-1:2.5-2  xf86-input-evdev-2.10.1-1
              xf86-video-r128-6.10.1-0.1  xfsprogs-4.3.0-1  xorg-xrdb-1.1.0-2  xterm-322-1

Total Download Size:    97.28 MiB
Total Installed Size:  430.86 MiB
Net Upgrade Size:       29.38 MiB

:: Proceed with installation? [Y/n] 
And any successive system update he will be presented with a shorter (if launched soon after initial update) or bigger (e.g. launched the next time he uses his live system, might be days, or weeks).

A third option would be to skip this additional step (system update). But then and on top of security breaches (highly probable) the Porteus Nemesis user won't be able to install and use hhundred of additional applications (reason behind this being B below).

If going --> the Porteus way (pman) that'll make a hell of modules added and to be proceeded upon each boot (I let you imagine after a few months :( ), keep the ability to go Fresh (initial state) in case an update goes a bit mad. While if going --> the Arch way, well, all I know is that with 'changes=' this folder/file.dat will grow exponentialy, keep Fresh as well, and with no way to revert an update while keeping one's changes --that's unless I'm mistaking.

Quite some implications in the choice between the two updating ways, ain't it.

QUESTION considering
A - Porteus Nemesis is a modular system often used as a live OS. Means freedom of what you load upon boot (like e.g. TinyCore), flash memory and/or low space avaible
B - Is based on the rolling-release (understand: has a steady flows of updates) Arch Linux distro

Which of the two sys-update method do you suggest and why?

beny
Full of knowledge
Full of knowledge
Posts: 723
Joined: 02 Jan 2011, 11:33
Location: italy

Re: Update method of choice: Porteus vs Arch way?

Post#2 by beny » 31 Jan 2016, 15:48

hi porteus=slackware nemesis=arch or manjaro,when you use pman you can merge the packages into one i have used for kde and other software,but i think isn't a good idea to upgrade a system that have a lot of software already installed so a lot of libs version that you can't remove from a core system,also the kernel of nemesis have something hardcoded into it no way to upgrade it,tested, and i have used the config of nemesis,with porteus no problems at all, you can do the task of change kernel without modify the initrd.xz,so try to upgrade the system if you use abs brokenman have to put on server a devel package that work on the new kernel version,i have see the old one yet. ps: you can edit the pman.config for skip the packages upgrade like kernel or gtk or what you want....

datruche
Black ninja
Black ninja
Posts: 95
Joined: 20 Sep 2015, 21:02
Distribution: Arch, Porteus-Nemesis 3.5
Location: London > . < Paris

Re: Update method of choice: Porteus vs Arch way?

Post#3 by datruche » 31 Jan 2016, 15:52

Merging each updates in a module:
If updating every week (which is *low* yet acceptable pace in Arch) will make 27 modules after six months only for the updates.

beny
Full of knowledge
Full of knowledge
Posts: 723
Joined: 02 Jan 2011, 11:33
Location: italy

Re: Update method of choice: Porteus vs Arch way?

Post#4 by beny » 31 Jan 2016, 15:55

hi remeber that nemesis is a read only system,not a rolling release,maybe you have to choose what you have to upgrade or not.

User avatar
brokenman
Site Admin
Site Admin
Posts: 5456
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Update method of choice: Porteus vs Arch way?

Post#5 by brokenman » 31 Jan 2016, 16:12

If updating every week (which is *low* yet acceptable pace in Arch) will make 27 modules after six months only for the updates.
Once you are happy with the updates you can merge these 27 modules into one. Do you think it would be a better option to offer a 'porteus' update in which the base modules are replaced every so often after testing? Users could have the choice of updating alone using pacman or updating officially using porteus update.

Let me know what you think, or of any other ideas you may have.
How do i become super user?
Wear your underpants on the outside and put on a cape.

donald
Full of knowledge
Full of knowledge
Posts: 1158
Joined: 17 Jun 2013, 13:17
Distribution: Porteus 3.2.2 XFCE 32bit
Location: Germany

Re: Update method of choice: Porteus vs Arch way?

Post#6 by donald » 31 Jan 2016, 18:13

Hmmm...If I merge the updates into one module, would it even be possible
to update the updates?
---------------------------------
Personally I prefer to have updated base modules from time to time.
from an "officially store"

roadie
Full of knowledge
Full of knowledge
Posts: 205
Joined: 02 Jan 2011, 18:41
Distribution: Porteus 3.5...with a twist
Location: In a hayfield

Re: Update method of choice: Porteus vs Arch way?

Post#7 by roadie » 31 Jan 2016, 19:10

donald wrote:Hmmm...If I merge the updates into one module, would it even be possible
to update the updates?
---------------------------------
Personally I prefer to have updated base modules from time to time.
from an "officially store"
I think this might be the best way, then potential bugs are worked out as opposed to a new user running into problems. Though this problem is mostly mitigated, using Manjaro repos, it's still there.

Security/urgent fixes could be made available as an xzm on site?

I don't see the need to update weekly, my updates tend to be an entirely new release.

User avatar
Ed_P
Contributor
Contributor
Posts: 3154
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 3.2.2 64-bit ISO
Location: Western NY, USA

Re: Update method of choice: Porteus vs Arch way?

Post#8 by Ed_P » 31 Jan 2016, 19:22

datruche wrote:If going --> the Porteus way (pman) that'll make a hell of modules added and to be proceeded upon each boot (I let you imagine after a few months :( ), keep the ability to go Fresh (initial state) in case an update goes a bit mad. While if going --> the Arch way, well, all I know is that with 'changes=' this folder/file.dat will grow exponentialy, keep Fresh as well, and with no way to revert an update while keeping one's changes --that's unless I'm mistaking.
Oh, I don't like the sounds of this at all. Our 300 MB systems rapidly growing to 3 GB systems and up. Good bye USB installs.

Wasn't expecting this aspect of Nemesis.
Ed

User avatar
francois
Contributor
Contributor
Posts: 4942
Joined: 28 Dec 2010, 14:25
Distribution: kde xfce porteus manjaro kubun
Location: Enfin l'été, le changement climatique attendu: le soleil.

Re: Update method of choice: Porteus vs Arch way?

Post#9 by francois » 31 Jan 2016, 19:40

I go for Donald proposition. :)

Personally I prefer to have updated base modules from time to time.
from an "officially store

Bimonthly or monthly, or according to the user's choice would be good, but no faster than that. The question here would be:
1.0 how could porteus take into account the packages installed by the user. Personally I prefer to have updated porteus stock modules from time to time. In addition,

2.0 how would the non official packages of AUR be taken into account. But here maybe, we could for the time being say that there is no support for AUR.
Voltaire: Le mieux est l'ennemi du bien.

datruche
Black ninja
Black ninja
Posts: 95
Joined: 20 Sep 2015, 21:02
Distribution: Arch, Porteus-Nemesis 3.5
Location: London > . < Paris

Re: Update method of choice: Porteus vs Arch way?

Post#10 by datruche » 31 Jan 2016, 19:50

I see two steps here.

1/ Nemesis pre-release testers:

Cannot install a variety of applications without updating first.

Which of the available ways do you devs and 'in-house' persons advise us to achieve this so that we can test?

Brokenman you're building Nemesis, pman and tools; therefore you have some light we're missing. Please don't forget testers; they tend to be part of any succesful open source project.

2/ Upon the release of Porteus Nemesis
Ed_p wrote:Wasn't expecting this aspect of Nemesis.
Yeah that's why I posted (and didn't e.g. in 'Future of Porteus' before getting in Nemesis for a few weeks).

Code: Select all

-rw-r--r-- 1 root root 109M Jan 31 17:16 maj-20160131.xzm
First maj XZM is 109 MiB. How much RAM, room and processing power will it takes to merge a couple of them, so that we get an idea about Nemesis minimal hardware requirements (*)?
Roadie wrote:
donald wrote:Personally I prefer to have updated base modules from time to time.
from an "officially store"
I think this might be the best way, then potential bugs are worked out as opposed to a new user running into problems. Though this problem is mostly mitigated, using Manjaro repos, it's still there.

Security/urgent fixes could be made available as an xzm on site?

I don't see the need to update weekly,
Seems like a point!
francois wrote:Bimonthly or monthly, or according to the user's choice would be good, but no faster than that. The question here would be:
Can the devs set some optimal rhythm or does Nemesis mother OS Arch rolling and bleeding edge update system lead the pace? That's how a ten years Arch user like me see this question.

(*) Please help have some sort of visibility on the project. We shoudln't have to find such critical part of an OS specs' sheat by ourselves; that'd make many people all investing sparse time just to find the same bit of information.
Atm, the whole OS visibility is on pair with its developement subforum in: Forum ‹ Other ‹ Porteus derivatives ‹ Nemesis Arch based Porteus :unknown:

User avatar
brokenman
Site Admin
Site Admin
Posts: 5456
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Update method of choice: Porteus vs Arch way?

Post#11 by brokenman » 31 Jan 2016, 20:39

Hmmm...If I merge the updates into one module, would it even be possible to update the updates?
There should be no problem. A script could diff the existing update module and the new updates and remove what was updated in the old module, before merging the old update and the new update. This does present many confusing layers to code through. But possible.
Oh, I don't like the sounds of this at all. Our 300 MB systems rapidly growing to 3 GB systems and up. Good bye USB installs.
Can you still buy USB devices under 4Gb? Anyway, in theory, updates will not add any extra weight. They are exactly the same package, just updated. Downloading extra modules is exactly the same as slackware porteus. I fail to see the difference.
1.0 how could porteus take into account the packages installed by the user. Personally I prefer to have updated porteus stock modules from time to time.
Additional packages should be stored as modules exactly the same as in Porteus Slackware. Updates should replace the original package.
2.0 how would the non official packages of AUR be taken into account. But here maybe, we could for the time being say that there is no support for AUR.
The same way they are handled in arch. You will need to manually update and replace the existing module.
Which of the available ways do you devs and 'in-house' persons advise us to achieve this so that we can test?
Exactly the same way as arch does. If you are saving changes then you don't even have to create a module. If you are working with modules then think of them as the same as the arch package that usually gets left in /var/cache/pacman/packages. You just update and then remove the old module from your modules folder. This needs to be done manually at the moment until I get around to improving the wrapper.
First maj XZM is 109 MiB. How much RAM, room and processing power will it takes to merge a couple of them, so that we get an idea about Nemesis minimal hardware requirements (*)?
I don't fully understand the question. The specs to run Porteus remain the same for LXDE. To be safe I would say as a minimum 512Mb ram. If you can boot Porteus then you have the processing power to merge modules. Space is dependent on how many modules you have, and how big your storage device is.
Can the devs set some optimal rhythm or does Nemesis mother OS Arch rolling and bleeding edge update system lead the pace? That's how a ten years Arch user like me see this question.
Nemesis is Manjaro based. The updates are pushed through a little slower than arch. Users can update whenever they like. If it is a porteus update mechanism that gets implemented, then I would update once a month, outside of security patches.
Please help have some sort of visibility on the project. We shouldn't have to find such critical part of an OS specs' sheat by ourselves
Look, If your expecting a mature OS with a set spec sheet and a clear long term plan then you'd better stop using Nemesis immediately. Nemesis is in alpha and as such is still open to changing ANY part of the system at ANY time. I suggest you don't plan your '10 year user' outlook based on Nemesis alpha or you will be back here complaining before too long. I asked for users who want to test Nemesis, provide feedback and help to improve it. I didn't ask for testers that demand a clear long term plan while the project is in alpha. If you want to help test aspects of the system and give useful feedback on how to improve it, then nemesis is for you. If you want a stable work system that you can rely on, you shouldn't be here.

There is as yet no definitive direction for Porteus. It may be that we adopt slackware 14.2 for the next release while Nemesis is still being pushed through it's paces. In either case I will continue to be as transparent as I have always been regarding the 'visibility' of the project.

EDIT ... IMPORTANT FOR EVERYONE
I see the following in another post made by you.
what else than kernel, initrd, base modules --and the 'changes' folder or .dat file ned to be replaced for swipping to the next alpha release? Note that I for example use Nemesis as my *working* OS
To preempt a potentially explosive situation I want to be crystal clear. I have said it before but you insist on doing it your way. I don't recommend, nor support upgrades of the alpha versions. You should download and replace the old ISO to prevent any cataclysmic failures. Obviously I don't recommend, nor support using this volatile alpha release for a stable *working* machine. This is just asking for trouble and I won't be responsible for anything untoward that becomes of your work data as a result of not following my advice. You have been warned.
How do i become super user?
Wear your underpants on the outside and put on a cape.

roadie
Full of knowledge
Full of knowledge
Posts: 205
Joined: 02 Jan 2011, 18:41
Distribution: Porteus 3.5...with a twist
Location: In a hayfield

Re: Update method of choice: Porteus vs Arch way?

Post#12 by roadie » 31 Jan 2016, 20:46

@datruche
First maj XZM is 109 MiB. How much RAM, room and processing power will it takes to merge a couple of them, so that we get an idea about Nemesis minimal hardware requirements (*)?
I know my dual core Atom and 1 Gig of ram handles it fine, max's it out for sure. I do a lot more than 109 Mib at one time.

(*) Please help have some sort of visibility on the project. We shoudln't have to find such critical part of an OS specs' sheat by ourselves; that'd make many people all investing sparse time just to find the same bit of information.
Atm, the whole OS visibility is on pair with its developement subforum in: Forum ‹ Other ‹ Porteus derivatives ‹ Nemesis Arch based Porteus

Nemesis is new to pretty much everyone who was using Porteus, I believe Arch is new to brokenman. So, there is a learning curve with it, including OS specs and the like. Right now, Nemesis IS a Porteus derivative, an experiment....it hasn't been announced that it will be adopted as a new Porteus....Slackware is still in the running so far as I know.

Have you read 'Future of Porteus'? It's all in the first few pages.....and, there are no devs...as in plural...it's one guy who puts out Porteus/Nemesis....I have no idea why he does, I'd be sitting on the damn beach sipping on some funny drink....I hear bikinis are basically a string, where he lives.

User avatar
brokenman
Site Admin
Site Admin
Posts: 5456
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Update method of choice: Porteus vs Arch way?

Post#13 by brokenman » 31 Jan 2016, 20:58

I have no idea why he does, I'd be sitting on the damn beach sipping on some funny drink....I hear bikinis are basically a string, where he lives.
I am sitting on a beach with a funny drink, but I have a laptop with me and a bad wifi connection. The bikinis do in fact resemble a piece of string. This is sometimes very pleasant and other times quite disturbing.
How do i become super user?
Wear your underpants on the outside and put on a cape.

roadie
Full of knowledge
Full of knowledge
Posts: 205
Joined: 02 Jan 2011, 18:41
Distribution: Porteus 3.5...with a twist
Location: In a hayfield

Re: Update method of choice: Porteus vs Arch way?

Post#14 by roadie » 31 Jan 2016, 22:15

brokenman wrote:
I have no idea why he does, I'd be sitting on the damn beach sipping on some funny drink....I hear bikinis are basically a string, where he lives.
I am sitting on a beach with a funny drink, but I have a laptop with me and a bad wifi connection. The bikinis do in fact resemble a piece of string. This is sometimes very pleasant and other times quite disturbing.

Ya, life can be a beach....good that you at least have the laptop to look at.

aus9

Re: Update method of choice: Porteus vs Arch way?

Post#15 by aus9 » 31 Jan 2016, 23:20

Ed_P wrote:snip. Our 300 MB systems rapidly growing to 3 GB systems and up. Good bye USB installs.
Ed certain facts are true and some more true than others :D

Let me try and explain without having installed KDE in years I believe anyone maintainting DE is likely to exceed 300 Mb unpacked size, I think francos runs KDE so it will be interesting to see what he says on a non-Nemesis system.

Verdict unpacked size is affected by the DE/WM chosen as well as the type of distro.

2) I run 64 bit LXDE v 3.5 and my total unpacked for porteus including the changes folder (dir) is 3.4G but I run it on a hard drive partition.

3) In Australia you can buy a 8G usb stick for about $5 and 16G for about $10 so its not like its the end of USB installs.

cheers

Post Reply