Matthew Miller wrote:
> Sure, that's fair. Here's the goal: users will have more options
> without exponentially increasing work for packagers and
> distro-creators.
The exponential number of combinations will still exist, it will just be out
of our, or really anybody's, control. It is impossible
De: "Kevin Kofler"
Matthew Miller wrote:
>> And, it will also allow those of us working on assembling spins and more
>> options — for example, we can have different streams for Atomic without
>> needing to actually duplicate every package. (And we could do the same for
>> KDE or whatever other a
On 2017-08-28, Matthew Miller wrote:
>> > Modularity will allowing *us* at the packaging end to separate source
>> > and spec lifecycle from binary and artifact lifecycle.
>> That, by itself, is not a goal. It is a way to achieve an unspecified goal.
>
> Sure, that's fair. Here's the goal: users
On Sat, Aug 26, 2017 at 04:04:27AM +0200, Kevin Kofler wrote:
> You could actually just have skipped the October-November release as you did
> during the F21 cycle, leading to a single 9-month cycle, then back to 6
> months. I think a 9-month cycle would be much more realistic than a 3-month
> c
On Fri, Aug 25, 2017 at 07:26:20PM -0400, Ben Rosser wrote:
> I have similar concerns and frustrations as Neal does, I think.
>
> I first want to comment that I appreciate your willingness to engage
> people (like Neal, and like myself) who seem frustrated with the
> future direction of Fedora. An
On Mon, Aug 28, 2017 at 4:34 AM, Kevin Kofler wrote:
> Neal Gompa wrote:
>> RPM itself is now sufficiently advanced that it can take on all the
>> roles of composition group metadata. They would essentially be transformed
>> into metapackages. This has already happened on the SUSE side, where
>> t
Neal Gompa wrote:
> RPM itself is now sufficiently advanced that it can take on all the
> roles of composition group metadata. They would essentially be transformed
> into metapackages. This has already happened on the SUSE side, where
> their patterns are now just metapackages with Provides that t
On Sun, Aug 27, 2017 at 7:57 PM, Kevin Kofler wrote:
> Igor Gnatenko wrote:
>> Can we finally kill this comps stuff please?
>
> Please no! AppStream is no suitable replacement, due to limitations both of
> the spec and of its implementation in Fedora. E.g., where are the -devel
> packages in Fedor
Igor Gnatenko wrote:
> Can we finally kill this comps stuff please?
Please no! AppStream is no suitable replacement, due to limitations both of
the spec and of its implementation in Fedora. E.g., where are the -devel
packages in Fedora AppStream metadata? They are in comps. There are more
such
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2017-08-25 at 16:23 -0400, Matthew Miller wrote:
> On Fri, Aug 25, 2017 at 10:06:42AM -0400, Neal Gompa wrote:
> [snip]
>
> Thanks Neal. This is much more useful and I appreciate you taking the
> time despite the frusturation.
>
> > I'm ext
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, 2017-08-26 at 15:13 +0200, Emmanuel Seyman wrote:
> * Matthew Miller [25/08/2017 16:23] :
> >
> > From a user perspective,
> > https://apps.fedoraproject.org/packages/ works very well for me
> > (and
> > it's _way
* Matthew Miller [25/08/2017 16:23] :
>
> From a user perspective,
> https://apps.fedoraproject.org/packages/ works very well for me (and
> it's _way_ faster than it was several years ago).
I would agree if it wasn't for packages' issue #286
I suspect that packages use
Matthew Miller wrote:
> I hear three different main frustrations here: first, the short F27
> schedule; second, frustration with with the packagedb retirement; and
> third, modularity.
These are frustrations I also share:
> Schedule
>
[snip]
> If, instead, we lengthened the schedule, ad
On Fri, Aug 25, 2017 at 4:23 PM, Matthew Miller
wrote:
> Modularity will allowing *us* at the packaging end to separate source
> and spec lifecycle from binary and artifact lifecycle. And, it will
> also allow those of us working on assembling spins and more options —
> for example, we can have di
On Fri, Aug 25, 2017 at 10:06:42AM -0400, Neal Gompa wrote:
[snip]
Thanks Neal. This is much more useful and I appreciate you taking the
time despite the frusturation.
> I'm extremely frustrated by how much half-baked-ness has been going on
> in the last couple of months. Schedule shrinkage, feat
On Fri, Aug 25, 2017 at 12:17 PM, Stephen John Smoogen wrote:
> On 25 August 2017 at 10:06, Neal Gompa wrote:
>> On Fri, Aug 25, 2017 at 9:42 AM, Rex Dieter wrote:
>>> Neal Gompa wrote:
>>>
On Fri, Aug 25, 2017 at 8:54 AM, Matthew Miller
wrote:
> On Fri, Aug 25, 2017 at 08:25:22AM
On 25 August 2017 at 10:06, Neal Gompa wrote:
> On Fri, Aug 25, 2017 at 9:42 AM, Rex Dieter wrote:
>> Neal Gompa wrote:
>>
>>> On Fri, Aug 25, 2017 at 8:54 AM, Matthew Miller
>>> wrote:
On Fri, Aug 25, 2017 at 08:25:22AM -0400, Neal Gompa wrote:
> This is a stupid idea because it introd
On Fri, Aug 25, 2017 at 9:42 AM, Rex Dieter wrote:
> Neal Gompa wrote:
>
>> On Fri, Aug 25, 2017 at 8:54 AM, Matthew Miller
>> wrote:
>>> On Fri, Aug 25, 2017 at 08:25:22AM -0400, Neal Gompa wrote:
This is a stupid idea because it introduces "magic" into picking the
type of thing instal
Neal Gompa wrote:
> On Fri, Aug 25, 2017 at 8:54 AM, Matthew Miller
> wrote:
>> On Fri, Aug 25, 2017 at 08:25:22AM -0400, Neal Gompa wrote:
>>> This is a stupid idea because it introduces "magic" into picking the
>>> type of thing installed. It also goes against how we typically do
>>
>> Neal, th
On Fri, Aug 25, 2017 at 09:15:03AM -0400, Neal Gompa wrote:
> I'm going to be blunt about how I feel about it and present my
> technical argument. Being purely technical tends to lead to being
> ignored. You noticed because I didn't do that.
No. I noticed because I read and think about every messa
On Fri, Aug 25, 2017 at 8:54 AM, Matthew Miller
wrote:
> On Fri, Aug 25, 2017 at 08:25:22AM -0400, Neal Gompa wrote:
>> This is a stupid idea because it introduces "magic" into picking the
>> type of thing installed. It also goes against how we typically do
>
> Neal, this idea is the idea of other
On Fri, Aug 25, 2017 at 08:25:22AM -0400, Neal Gompa wrote:
> This is a stupid idea because it introduces "magic" into picking the
> type of thing installed. It also goes against how we typically do
Neal, this idea is the idea of other Fedora contributors who have put a
lot of thought into it. Ple
On Thu, Aug 24, 2017 at 7:44 AM, Stephen Gallagher wrote:
>
>
> On Thu, Aug 24, 2017 at 3:02 AM Marius Vollmer
> wrote:
>>
>> My understanding from playing with Boltron is that "dnf install foo"
>> treats "foo" as a module name. "dnf install" can not install packages
>> anymore. So naively I as
Stephen Gallagher writes:
> That being said, the implementation is still under debate.
Thanks for the clarification!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Hi,
I suspect the confusion between group and module names will lead to strange
brittle special cases down the road and (worse) people being over-clever
building solutions that rely on those special cases (exactly like the
under-specified rpm update quirks which are being blamed nowadays).
Why
Dne 24.8.2017 v 09:00 Marius Vollmer napsal(a):
My understanding from playing with Boltron is that "dnf install foo"
treats "foo" as a module name. "dnf install" can not install packages
The final solution will be:
dnf install foo - install rpm package
dnf module install foo - install modu
On Thu, Aug 24, 2017 at 3:02 AM Marius Vollmer
wrote:
> My understanding from playing with Boltron is that "dnf install foo"
> treats "foo" as a module name. "dnf install" can not install packages
> anymore. So naively I assume that PackageKit will transparently start
> installing modules. (I
Richard Hughes writes:
> On 24 August 2017 at 08:45, Marius Vollmer wrote:
>
>> One approach is just to put them all into the collection data:
>
> You can't have two components with the same ID inside a
> group with the same origin.
Okay, that was my understanding of the spec as well.
>> My p
On 24 August 2017 at 08:45, Marius Vollmer wrote:
> If appstream-builder finds two packages that both contain metainfo for
> the same component id, what does it do?
If I understand correctly, in appstream-builder it's an error, and the
"first encountered" component wins.
> What should it do? W
Richard Hughes writes:
> On 23 August 2017 at 13:57, Marius Vollmer wrote:
>
>> I propose to keep AppStream metainfo data in packages, and map from
>> package names to module names during construction of the collection
>> data.
>
> Can you elaborate a bit? At the moment in Fedora we generate the
Owen Taylor writes:
> The current expectation is that the only way that modules are going to
> show up in GNOME Software is when they are safely wrapped up as a
> Flatpak.
Ah, that's nice. If we follow the same line for Cockpit, we would only
show container images. This would certainly simplif
Richard Hughes writes:
> On 23 August 2017 at 13:57, Marius Vollmer wrote:
>
>> - Metainfo is in packages, but we need to be installing modules.
>
> How are we going to be installing modules in a modular-system?
> PackageKit is only going to be able to install packages so
> gnome-software will
On Wed, 2017-08-23 at 17:25 +0100, Richard Hughes wrote:
> On 23 August 2017 at 13:57, Marius Vollmer wrote:
> > In a modular repository, I think the same thing should happen so that
> > GNOME Software can present interesting modules to the user in a nice
> > way.
>
> What kind of modules would b
On 23 August 2017 at 13:57, Marius Vollmer wrote:
> In a modular repository, I think the same thing should happen so that
> GNOME Software can present interesting modules to the user in a nice
> way.
What kind of modules would be shown in gnome-software? Are
applications like Firefox going to be
Hi,
what happens when the packages in a module contain AppStream metainfo
files?
In a non-modular repository, all these metainfo files get collected into
a big AppStream collection file which is then used by GNOME Software
(for example) to present interesting packages to the user in a nice way.
35 matches
Mail list logo
