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 we
pass the artifact
-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
> > > wrote:
> > > > It sounds like it would ma
-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 for createrepo_c to link
> > > to
> > > the
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 handle AppStream metadata processing
>>> 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 handle AppStream metadata processing
>> as part of the createrepo_c repodata generation, wouldn't
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 deal with appstream is to add the appstrea
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:
>> > > The correct way to deal with appstream is to add th
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
>> > rpm headers and then teach createrepo
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 to
> > > rpm headers and then teach cre
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
> > files.
>
> I'm sur
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 part of the createrepo_c repodata generatio
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 take some time curren
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
>> files.
>
> I'm sure we've had this di
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 single package contai
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 e
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 -- devel@lists.fed
/*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 appstream-data package.
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 me.
> You can see th
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, Mageia, and even in COPR).
>>
>> We should be making
-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. Cockpit will do the right t
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
> third-class. :(
Thi
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 cockpit data in
> appstream-data and the
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 installed.
I have n
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 AM, Marius Vollmer
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 AM, Marius Vollmer
wrote:
Neal Gompa writes:
So, what about creating a dedicated appstream-data-server package that
carries
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 dedicated appstream-data-server package that
> carries only those co
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 Server?
Initially, it would contain only components o
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
>>> "cockpit.desktop", and co
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 contain only components of type "addon" that exten
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 type "service".
>
>
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
> install for a desktop environmen
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 also
32 matches
Mail list logo
