Re: [arch-general] Announcing pacpak
On Monday 11 July 2016 18:57:38 pelzflorian wrote: > On 07/11/2016 05:01 PM, Maxwell Anselm via arch-general wrote: > > I think the tool is great Florian, but I do not think that it warrants > > official support. Consider examples like pacgem or pip2pkgbuild. These > > tools help integrate Ruby/Python packages (which are usually managed via a > > separate package manager) into pacman. They are great for users who want > > pacman to be the single package manager for their entire system, but they > > are still just AUR packages without official support. > > I agree. This is a reasonable argument at least until Flatpak becomes > much more popular. I will set it up elsewhere. Florian, What is the target user of pacpak? Arch users or App developers? I think Flatpak and Arch rolling release model mainly fix the same issue: Shipping cutting edge softwares quickly and stay close with upstream. Arch users will find flatpak less necessary as long as the package is rolling out quickly enough. For pacpak, it will be great if it could archive below working flow: 1. Upstream develop software on Arch, stay cutting edge. 2. Developer build packages using pacpak. 3. Those packages does not target Arch user, but other distro users. 4. Then app becomes a rolling application. And the running environment is just a subset of Arch linux. Security issues are fixed as quickly as us (Arch linux). Feng Chao > > Regards, > Florian Pelz
Re: [arch-general] Mono package updates
No worries, we all have competing priorities. Ok, thanks for the info, and for looking into the update.
Re: [arch-general] arch-general Digest, Vol 141, Issue 17
On 07/11/2016 01:00 AM, arch-general-requ...@archlinux.org wrote: > On 07/11/2016 01:09 AM, Information Technology Works wrote: >> > Aren't snaps, flatpak and appimage missing the boat in a concerning >> > way? Shouldn't the Gnu+Linux ecosystem be focusing on automating the >> > package building/maintenance instead? A layer above distros' package >> > managers(pacman, apt, etc) that can build upstream from source without >> > human intervention. Maybe upstream would have to cooperate in some way? >> > Every distro would just have to write a plugin/config for themselves >> > that described how their packages should be built, then their package >> > manager can be used to install binaries like now. Distro devs could >> > develop the system and verify it's integrity/security or do distro >> > feature related work instead of packaging. This would address all the >> > problems that these app container based systems are trying to solve >> > while keeping dependency resolution, repos, etc. in tact. Is this >> > impossible/wrong for some reason? >> > > Hello, > > Work is being done in this area [1], but it?s not as fancy as you may > think. It?s mostly about upstream using a well-behaved build system. > Well-behaved software is easy to package anyway (just do `./configure > --prefix=/usr`, `make` and `make install`). When customization is > necessary or desired, pacman brings the needed versatility. > > Please note that ?build once, run anywhere? is not the only advantage of > Flatpak and not one pacpak addresses. To me, containerization mostly > provides added security by privilege revocation and separation of > privileges. > > Regards, > Florian Pelz > > [1] https://github.com/cgwalters/build-api Florian, thanks for the reply and link. Well behaved build systems and/or the link you sent is what i alluded to with my "cooperation from upstream" comment. It seems to me, upstream and distros should get together and agree on a set of standards. then all distros could auto-build their repos. Unless "build once, run everywhere" can be done in a way that's superior to repos and packages (i don't see how, but what do i know), it seems like the wrong approach and would be completely unecessary with all distros having near instant packages from upstream due to automation. I'm not necessarily opposed to the theoretical, potential security benefits of app containerization but minus the dependency compat layer, especially if automation of building is not so out of reach. Your package sounds interesting and good luck with it, i just thought i'd bring up these questions before we throw the baby out with the bath water. thanks, ITwrx
Re: [arch-general] Announcing pacpak
On 07/11/2016 06:14 PM, G. Schlisio wrote: > […] > an install command would likely look like -S like in pacman? > whats the base for installation? PKGBUILDs (from AUR/ABS), official > repos, some new platform containing build recipes for pacpak? > pacpak will use the official repos (or other repos depending on the pacman.conf that is used) with the -S option and *.pkg.tar.gz with the -U option. Making -U accept PKGBUILDs directly seems like a useful feature though. >> `pacpak -Syu` would therefore always install exactly the same version of >> the software as available with regular pacman. > > -Syu with pacman means refresh databases and install all available > updates. does this mean pacpak execute this logic on all installed > containers as pacman executes on all installed packages? especially the > refresh part makes no sense to me at this point. what external database > is there to refresh? > > […] >> it can be used to create containers from existing Arch packages. > > sounds like working from /var/cache/pacman. > Since pacpak should be used without root privileges, I cannot use /var/cache/pacman as the package cache. In fact, I’d like to use an unprivileged pacpak-exclusive user for running pacman. pacpak will probably use one package cache per app. Packages common to multiple apps and their caching will be shared. (Flatpak uses runtime + SDK platforms on top of which apps as well as other platforms can be built. Many apps can share the same platform with its files.) `pacpak -Syu` would therefore refresh and upgrade each platform and then each app running on top of it. What I’m not sure about is whether anyone would want to only upgrade without refreshing. Probably there are some exceptional situations where the answer is yes. > i generally like the idea of isolating and running untrusted software, > as it allows one to implement sth like an applicationwise firewall (as > done in android. wether this reduces or increases attack surface heavily > depends on the implementation and its possibilities, but running > malicious software will never be safe. this only adds another layer of > control to the os. > > georg > It won’t be completely safe. I will add a reminder for new pacpak users to make sure they are aware of this as well. Regards, Florian Pelz
Re: [arch-general] Announcing pacpak
On 07/11/2016 05:01 PM, Maxwell Anselm via arch-general wrote: > I think the tool is great Florian, but I do not think that it warrants > official support. Consider examples like pacgem or pip2pkgbuild. These > tools help integrate Ruby/Python packages (which are usually managed via a > separate package manager) into pacman. They are great for users who want > pacman to be the single package manager for their entire system, but they > are still just AUR packages without official support. > I agree. This is a reasonable argument at least until Flatpak becomes much more popular. I will set it up elsewhere. Regards, Florian Pelz signature.asc Description: OpenPGP digital signature
Re: [arch-general] Announcing pacpak
> `pacpak -Syu` would therefore always install exactly the same version of > the software as available with regular pacman. -Syu with pacman means refresh databases and install all available updates. does this mean pacpak execute this logic on all installed containers as pacman executes on all installed packages? especially the refresh part makes no sense to me at this point. what external database is there to refresh? an install command would likely look like -S like in pacman? whats the base for installation? PKGBUILDs (from AUR/ABS), official repos, some new platform containing build recipes for pacpak? > it can be used to create containers from existing Arch packages. sounds like working from /var/cache/pacman. i generally like the idea of isolating and running untrusted software, as it allows one to implement sth like an applicationwise firewall (as done in android. wether this reduces or increases attack surface heavily depends on the implementation and its possibilities, but running malicious software will never be safe. this only adds another layer of control to the os. georg signature.asc Description: OpenPGP digital signature
Re: [arch-general] Announcing pacpak
On 07/11/2016 03:32 AM, 郑文辉(Techlive Zheng) via arch-general wrote: > Florian, I love it, the tool itself is a break-through, just depends how we > use it properly. > Thank you. I’m happy to get some positive feedback :) .
Re: [arch-general] arch-general Digest, Vol 141, Issue 16
On 07/11/2016 01:09 AM, Information Technology Works wrote: > Aren't snaps, flatpak and appimage missing the boat in a concerning > way? Shouldn't the Gnu+Linux ecosystem be focusing on automating the > package building/maintenance instead? A layer above distros' package > managers(pacman, apt, etc) that can build upstream from source without > human intervention. Maybe upstream would have to cooperate in some way? > Every distro would just have to write a plugin/config for themselves > that described how their packages should be built, then their package > manager can be used to install binaries like now. Distro devs could > develop the system and verify it's integrity/security or do distro > feature related work instead of packaging. This would address all the > problems that these app container based systems are trying to solve > while keeping dependency resolution, repos, etc. in tact. Is this > impossible/wrong for some reason? > Hello, Work is being done in this area [1], but it’s not as fancy as you may think. It’s mostly about upstream using a well-behaved build system. Well-behaved software is easy to package anyway (just do `./configure --prefix=/usr`, `make` and `make install`). When customization is necessary or desired, pacman brings the needed versatility. Please note that “build once, run anywhere“ is not the only advantage of Flatpak and not one pacpak addresses. To me, containerization mostly provides added security by privilege revocation and separation of privileges. Regards, Florian Pelz [1] https://github.com/cgwalters/build-api
