On 5 September 2017 at 07:37, Vít Ondruch wrote:
> Just another idea reading this ... could we move the AppStream data into
> subpackage?
First, that would be another ~2000 subpackages clogging up the mirrors
and metadata -- second it's really only a rel-eng artifact. Either
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, 2017-09-05 at 08:37 +0200, Vít Ondruch wrote:
>
> Dne 5.9.2017 v 08:31 Nicolas Chauvet napsal(a):
> > 2017-09-04 19:20 GMT+02:00 Richard Hughes :
> > > On 4 September 2017 at 17:56, Neal Gompa
> > >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, 2017-09-05 at 08:31 +0200, Nicolas Chauvet wrote:
> 2017-09-04 19:20 GMT+02:00 Richard Hughes :
> > On 4 September 2017 at 17:56, Neal Gompa
> > wrote:
> > > It sounds like it would make more sense
Dne 5.9.2017 v 08:31 Nicolas Chauvet napsal(a):
> 2017-09-04 19:20 GMT+02:00 Richard Hughes :
>> On 4 September 2017 at 17:56, Neal Gompa wrote:
>>> It sounds like it would make more sense for createrepo_c to link to
>>> the AppStream builder library to
2017-09-04 19:20 GMT+02:00 Richard Hughes :
> On 4 September 2017 at 17:56, Neal Gompa wrote:
>> It sounds like it would make more sense for createrepo_c to link to
>> the AppStream builder library to handle AppStream metadata processing
>> as part of the
Dne 4.9.2017 v 22:02 Dennis Gilmore napsal(a):
> El lun, 04-09-2017 a las 12:56 -0400, Neal Gompa escribió:
>> On Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes
>> wrote:
>>> On 4 September 2017 at 17:15, Dennis Gilmore
>>> wrote:
The correct way to
On Mon, Sep 4, 2017 at 4:02 PM, Dennis Gilmore wrote:
> El lun, 04-09-2017 a las 12:56 -0400, Neal Gompa escribió:
>> On Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes
>> wrote:
>> > On 4 September 2017 at 17:15, Dennis Gilmore
>> > wrote:
>>
On Mon, Sep 4, 2017 at 3:57 PM, Dennis Gilmore wrote:
> El lun, 04-09-2017 a las 17:33 +0100, Richard Hughes escribió:
>> On 4 September 2017 at 17:15, Dennis Gilmore wrote:
>> > The correct way to deal with appstream is to add the appstream data
>> > to
>> >
El lun, 04-09-2017 a las 12:56 -0400, Neal Gompa escribió:
> On Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes
> wrote:
> > On 4 September 2017 at 17:15, Dennis Gilmore
> > wrote:
> > > The correct way to deal with appstream is to add the appstream
> > > data
El lun, 04-09-2017 a las 17:33 +0100, Richard Hughes escribió:
> On 4 September 2017 at 17:15, Dennis Gilmore wrote:
> > The correct way to deal with appstream is to add the appstream data
> > to
> > rpm headers and then teach createrepo to make the appropriate
> > metadata
> >
On Mon, Sep 4, 2017 at 1:20 PM, Richard Hughes wrote:
> On 4 September 2017 at 17:56, Neal Gompa wrote:
>> It sounds like it would make more sense for createrepo_c to link to
>> the AppStream builder library to handle AppStream metadata processing
>> as
On 4 September 2017 at 17:56, Neal Gompa wrote:
> It sounds like it would make more sense for createrepo_c to link to
> the AppStream builder library to handle AppStream metadata processing
> as part of the createrepo_c repodata generation, wouldn't it?
100% agree. This does
On Mon, Sep 4, 2017 at 12:33 PM, Richard Hughes wrote:
> On 4 September 2017 at 17:15, Dennis Gilmore wrote:
>> The correct way to deal with appstream is to add the appstream data to
>> rpm headers and then teach createrepo to make the appropriate metadata
On 4 September 2017 at 17:15, Dennis Gilmore wrote:
> The correct way to deal with appstream is to add the appstream data to
> rpm headers and then teach createrepo to make the appropriate metadata
> files.
I'm sure we've had this discussion before, but:
* What happens if a
El vie, 01-09-2017 a las 13:37 +0300, Marius Vollmer escribió:
> Hi,
>
> I hope that soon the first Cockpit add-on appears in the Fedora
> repositories. Cockpit can find such add-ons via their AppStream
> metainfo data, similar to how GNOME Software finds applications to
> install for a desktop
I agree, 15MB is too much for a server instance, especially for a
container. I think AppStream data as is is more appropriate for
desktop. No sure if possible, but maybe an option; don't make it a
hard dependency.
___
devel mailing list --
/*Igor Gnatenko*/ wrote on Fri, 01 Sep 2017 15:19:34 +0200:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2017-09-01 at 16:01 +0300, Marius Vollmer wrote:
Neal Gompa writes:
Implement your AppStream filter at the application level, rather
than
messing with
Neal Gompa writes:
> All PackageKit based software managers automatically download the
> data, as the Dnf PK backend does this:
> https://github.com/hughsie/PackageKit/blob/master/backends/dnf/pk-backend-dnf.c#L553
Ahh, thanks! "pkcon refresh force" indeed downloads it for
On Fri, Sep 1, 2017 at 9:12 AM, Marius Vollmer
wrote:
> Neal Gompa writes:
>
>> [...] It's already kind of second-class in Fedora because it's not
>> properly integrated into our repodata (like it's supposed to be, and
>> how it is in openSUSE,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2017-09-01 at 16:01 +0300, Marius Vollmer wrote:
> Neal Gompa writes:
>
> > Implement your AppStream filter at the application level, rather
> > than
> > messing with appstream-data package.
>
> Yes, of course.
Neal Gompa writes:
> [...] It's already kind of second-class in Fedora because it's not
> properly integrated into our repodata (like it's supposed to be, and
> how it is in openSUSE, Mageia, and even in COPR).
>
> We should be making AppStream data support first-class, not
>
On Fri, Sep 1, 2017 at 9:03 AM, Richard Hughes wrote:
> On Fri, Sep 1, 2017 at 2:00 PM, Neal Gompa wrote:
>> It's not just about your vision of usage, it's about how everyone else
>> uses it too! :)
>
> Well, we could do the opposite, we could just include
Neal Gompa writes:
> Implement your AppStream filter at the application level, rather than
> messing with appstream-data package.
Yes, of course. Cockpit will do the right thing even with the full
appstream-data package. This is only about not having 15 MiB of useless
data
On Fri, Sep 1, 2017 at 8:57 AM, Alexander Bokovoy wrote:
> On pe, 01 syys 2017, Neal Gompa wrote:
>>
>> On Fri, Sep 1, 2017 at 8:37 AM, Alexander Bokovoy
>> wrote:
>>>
>>> On pe, 01 syys 2017, Neal Gompa wrote:
On Fri, Sep 1, 2017 at 7:52
On pe, 01 syys 2017, Neal Gompa wrote:
On Fri, Sep 1, 2017 at 8:37 AM, Alexander Bokovoy wrote:
On pe, 01 syys 2017, Neal Gompa wrote:
On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer
wrote:
Neal Gompa writes:
So, what
On Fri, Sep 1, 2017 at 8:37 AM, Alexander Bokovoy wrote:
> On pe, 01 syys 2017, Neal Gompa wrote:
>>
>> On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer
>> wrote:
>>>
>>> Neal Gompa writes:
>>>
> So, what about creating a
On pe, 01 syys 2017, Neal Gompa wrote:
On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer
wrote:
Neal Gompa writes:
So, what about creating a dedicated appstream-data-server package that
carries only those components that we want to see on a
Marius Vollmer wrote:
> Neal Gompa writes:
>
>>> So, what about creating a dedicated appstream-data-server package that
>>> carries only those components that we want to see on a Server?
>>>
>>> Initially, it would contain only components of type "addon" that extend
>>>
On Fri, Sep 1, 2017 at 7:52 AM, Marius Vollmer
wrote:
> Neal Gompa writes:
>
>>> So, what about creating a dedicated appstream-data-server package that
>>> carries only those components that we want to see on a Server?
>>>
>>> Initially, it would
Neal Gompa writes:
>> So, what about creating a dedicated appstream-data-server package that
>> carries only those components that we want to see on a Server?
>>
>> Initially, it would contain only components of type "addon" that extend
>> "cockpit.desktop", and components of
On Fri, Sep 1, 2017 at 6:37 AM, Marius Vollmer
wrote:
> Hi,
>
> I hope that soon the first Cockpit add-on appears in the Fedora
> repositories. Cockpit can find such add-ons via their AppStream
> metainfo data, similar to how GNOME Software finds applications to
>
Hi,
I hope that soon the first Cockpit add-on appears in the Fedora
repositories. Cockpit can find such add-ons via their AppStream
metainfo data, similar to how GNOME Software finds applications to
install for a desktop environment.
Thus, we would need to install the appstream-data package
32 matches
Mail list logo