Re: arch-general Digest, Vol 141, Issue 16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 07/10/2016 10:36 AM, arch-general-request@xxxxxxxxxxxxx wrote:
> Send arch-general mailing list submissions to
> 	arch-general@xxxxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.archlinux.org/listinfo/arch-general
> or, via email, send a message with subject or body 'help' to
> 	arch-general-request@xxxxxxxxxxxxx
>
> You can reach the person managing the list at
> 	arch-general-owner@xxxxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of arch-general digest..."
>
>
> Today's Topics:
>
>    1. Re: Announcing pacpak (pelzflorian (Florian Pelz))
>    2. Re: Announcing pacpak (pelzflorian (Florian Pelz))
>    3. Re: Announcing pacpak (Mauro Santos)
>    4. Re: Announcing pacpak (Jelle van der Waa)
>    5. Re: Announcing pacpak (Levente Polyak)
>    6. Re: Announcing pacpak (pelzflorian (Florian Pelz))
>    7. Re: Announcing pacpak (pelzflorian (Florian Pelz))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 10 Jul 2016 14:18:00 +0200
> From: "pelzflorian (Florian Pelz)" <pelzflorian@xxxxxxxxxxxxxx>
> To: arch-general@xxxxxxxxxxxxx
> Subject: Re:  Announcing pacpak
> Message-ID: <d3d5da50-9819-16f7-fe4a-daf922af799e@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=utf-8
>
> Hello,
>
> On 07/10/2016 12:52 PM, Bennett Piater wrote:
>> Are you planning to address the catastrophy that ensues when 5000
>> different versions of important libraries are installed at the same
>> time, most of which will always be 5 critical security updates behind?
>>
> The intention is that, once implemented, `pacpak -Syu` or maybe `pacpak
> -Su` will install a current version of all apps and runtimes. Old
> versions of apps and app runtimes that are not used by any app could be
> cleaned by `pacpak -Sc` or a similar command (or automatically?); I?m
> not yet sure what the best interface is.
>
> Note that there is a trade-off between memory consumption and the time
> it takes to update a container. ostree (which is used by Flatpak)
> compresses all runtimes and apps for about half the hard disk memory
> consumption. This greatly increases the time it takes to update a
> container. This may need to be addressed in ostree in the future.
>
>> I am very cynical about this container trend... :/
>>
> The advantage of using pacman for Flatpak is that even pure Flatpak
> users may still be interested in Arch packages, so Arch packages remain
> just as relevant and everything stays mostly the same for those using
> pure pacman.
>
> Regards,
> Florian Pelz
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 10 Jul 2016 14:18:24 +0200
> From: "pelzflorian (Florian Pelz)" <pelzflorian@xxxxxxxxxxxxxx>
> To: arch-general@xxxxxxxxxxxxx
> Subject: Re:  Announcing pacpak
> Message-ID: <985a680c-a132-862d-215c-8b8fc601e6b6@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=utf-8
>
> Hello,
>
> On 07/10/2016 01:59 PM, LoneVVolf wrote:
>> My personal preference though is for AL community to treat flatpak
>> similar as derivative distros.
>>
>> something like : flatpak is unsupported on Arch linux, ask the flatpak
>> creator(s) for help.
> Hm? If there is not that much desire to support Flatpak ?officially? as
> an Arch project, then I probably will end up setting up a mailing list
> and bug tracker on my server sometime in the coming weeks.
>
> Regards,
> Florian Pelz
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 10 Jul 2016 14:22:07 +0100
> From: Mauro Santos <registo.mailling@xxxxxxxxx>
> To: arch-general@xxxxxxxxxxxxx
> Subject: Re:  Announcing pacpak
> Message-ID: <83961152-99e0-b19a-c363-08526ee33e28@xxxxxxxxx>
> Content-Type: text/plain; charset=utf-8
>
> On 10-07-2016 13:18, pelzflorian (Florian Pelz) wrote:
>> Hello,
>>
>> On 07/10/2016 01:59 PM, LoneVVolf wrote:
>>> My personal preference though is for AL community to treat flatpak
>>> similar as derivative distros.
>>>
>>> something like : flatpak is unsupported on Arch linux, ask the flatpak
>>> creator(s) for help.
>> Hm? If there is not that much desire to support Flatpak ?officially? as
>> an Arch project, then I probably will end up setting up a mailing list
>> and bug tracker on my server sometime in the coming weeks.
>>
>> Regards,
>> Florian Pelz
>>
> Personally I'd rather keep using the good old packages _but_ it would be
> nice to have an official tool to manage/run/create flatpak packages,
> this just to make sure that in case one needs to use a flatpak package
> nothing will screw up the filesystem and cause more trouble than it's worth.
>
> However a big fat warning should be present somewhere that bugs/problems
> with flatpak packages are the sole responsibility of upstream/the
> creator as I suspect bugs and problems will be the norm.
>
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?



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux