Re: packaging ruby dependencies

[Miroslav Suchý]

Dne 25.10.2017 v 16:54 Jason Brooks napsal(a):
> getting the package into Fedora. Along the way[2], I encountered a
> bunch of required, unpackaged dependencies, which would also have to
> be added to Fedora.

BTW we have Copr repository with 45 000 ruby gems packaged as RPM:

https://copr.fedorainfracloud.org/coprs/g/rubygems/rubygems/

They are automatically generated. So it may or not work for you. Nevertheless 
it is good starting point.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[nicolas . mailhot]

> De: "Rich Megginson" 

Hi,

> I can't argue with that.

> What I can do is present my painful experience.

> I want to use fluentd (a medium sized ruby application) + a half dozen 
> or so plugins packaged as separate gems.

> This puts me on the hook to be the maintainer in perpetuity of 90+ ruby 
> RPM packages (for all of the build time and run time dependencies).  Not 
> what I had in mind.

I can certainly relate to that, I have need of another cloud native computing 
foundation project, prometheus, and what's in Fedora is awful (obsolete, 
incomplete, bitrotten specs, requiring a huge number of dep packaging or 
repackaging, packaging guideline updates and so on).

All I can say is someone needs to go first. Red Hat has IMHO missed the boat by 
focusing on paying devs to build its own cloud offering, with the usual dev 
bias of NIH-ism, unicorn-thinking, rewriting the world, building dev envs, dev 
containers, and not thinking about the practical aspects of making the result 
available in production or making users and ops happy in general.

And now there is a need to play catch-up, to make non Red Hat originated apps 
available in the software library, in the format Red Hat customers and Fedora 
contributors expect (which is *not* all the variations on custom containers 
which have constituted 90% of the cloud noise on Fedora lists in the past 
years). And that is a huge PITA because of past under-investments that need to 
be compensated first.

As a Red Hat customer, I certainly do not see the point of financing efforts 
that end up with me needing to pull third party code from github and rebuild 
container deployment images myself. I can do all that without paying Red Hat a 
penny, there is no lack of custom container variations on the marker.

As a Fedora contributor, I do not see the point of contributing packaging apps 
in a format that will help Red Hat earn money if Red Hat does not contribute a 
minimum to packaging apps in Fedora. That would be Debian with the constrains 
of a dominant sponsor and without the dominant sponsor earning its central 
place. I will do so for a while in the hope some sanity prevails, and switch 
partners if it does not.

Likewise, kuddos for buying ansible tower, for releasing awx, but why is it not 
in Fedora? Open but not ready to use in practice without  is open core-ism, 
I may as well standardise on saltstack and migrate to saltstack paying support 
when my use gets critical enough. 

The cloud market is entering a consolidation phase, it's the end of paying devs 
to do whatever they want in the hope of earning the jackpot, whoever focuses on 
grim practical tedious necessary aspects first will leave others actors in the 
dust.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: packaging ruby dependencies

[nicolas . mailhot]

Hi,

> I've done the "build the dependency chain" work myself with various
> projects I publish to github. The current problem I have is that for
> recent Fedora releases, I've not worked out how to add the local yum
> or dnf repositories to the "mock" configurations I've been working
> with for building the full chain locally, and being able to build them
> in mock. Does anyone have hooks or examples of how to do so for recent
> Fedora releases?

Here is my quick and dirty script. It's mostly missing a command to autobump 
release in specs on rebuild. Used both on EL7 and rawhide build hosts with 
minor adaptations.

You need a /srv/rpm directory writable by the mock user, and for each build env 
you target:
1. a build env id (mywork-rawhide for example)
2. a subdir in /srv/rpm with the same name (/srv/rpm/mywork-rawhide)
3. a mock conf with the same name (/etc/mock/mywork-rawhide.cfg, usually 
derived from the default mock conf of the build target)
4. config_opts['root'] = 'mywork-rawhide' in this conf file
5. Among the configured repos in this conf file :

[mywork-rawhide]
name= My private build repo for rawhide
baseurl=file:///srv/rpm/mywork-rawhide/
priority=1
gpgchek=0
metadata_expire=1s

(you want to sign the packages once they pass QA, not before)

Good practice is to wipe everything in the local repo once in a while and 
rebuild the whole package stack from specs to check everything still works 
together.

Regards,

-- 
Nicolas Mailhot

mass-rebuild.sh
Description: application/shellscript
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[Tom Hughes]

On 26/10/17 04:52, Nico Kadel-Garcia wrote:


I've done the "build the dependency chain" work myself with various
projects I publish to github. The current problem I have is that for
recent Fedora releases, I've not worked out how to add the local yum
or dnf repositories to the "mock" configurations I've been working
with for building the full chain locally, and being able to build them
in mock. Does anyone have hooks or examples of how to do so for recent
Fedora releases?


Just edit the relevant config file in /etc/mock and add it? So for 
example my local repo for f27 is defined by adding this block just 
before the """ marker at the end:


[compton]
name=compton
baseurl=http://packages.compton.nu/fedora-27/x86_64/
metadata_expire=30

Personally what I actually do is to create 
/etc/mock/compton-27-x86_64.cfg as a copy of 
/etc/mock/fedora-27-x86_64.cfg with that added to avoid conflicts on 
mock upgrades and then use the appropriate switch to mock/fedpkg to 
select that config.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[Nico Kadel-Garcia]

On Wed, Oct 25, 2017 at 3:43 PM,   wrote:
> Hi Jason,
>
> Packaging deps is a virtuous circle: it makes the work of the next person who 
> needs them for other software easier, which increases the chance other 
> software is packaged, which increases the value of the distro as a whole, its 
> attractiveness, and the probability that someone will eventually do something 
> useful for you (not limited to co-maintaining your packages). It's a long 
> term virtuous investment circle.
>
> Not packaging deps is less work in the short term, especially when you're 
> among the first to arrive on an underdeveloped part of the distro, but has no 
> positive externalities (and potentially negative ones as it can be 
> interpreted as a vote of no confidence in the distro, discouraging others).
>
> Believing in long term effects made Red Hat. Free software is the ultimate 
> long-term investment. It's a lot of work to make software available in a form 
> that may be consumed by others, without any guaranty someone will ever return 
> anything useful. Yet it is successful, because together people are stronger 
> than alone. Many entities that didn't understand this tried to outcompete Red 
> Hat by focusing on actions with immediate returns, and skimping on long shot 
> investments like sharing stuff with others. They had limited successes in 
> attracting long-term customers, in building communities, in getting others to 
> cooperate.
>
> We all like to receive, but to receive you need to give first.
>
> Regards,
>
> --
> Nicolas Mailhot

I've done the "build the dependency chain" work myself with various
projects I publish to github. The current problem I have is that for
recent Fedora releases, I've not worked out how to add the local yum
or dnf repositories to the "mock" configurations I've been working
with for building the full chain locally, and being able to build them
in mock. Does anyone have hooks or examples of how to do so for recent
Fedora releases?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[Rich Megginson]

On 10/25/2017 01:43 PM, nicolas.mail...@laposte.net wrote:

Hi Jason,

Packaging deps is a virtuous circle: it makes the work of the next person who 
needs them for other software easier, which increases the chance other software 
is packaged, which increases the value of the distro as a whole, its 
attractiveness, and the probability that someone will eventually do something 
useful for you (not limited to co-maintaining your packages). It's a long term 
virtuous investment circle.

Not packaging deps is less work in the short term, especially when you're among 
the first to arrive on an underdeveloped part of the distro, but has no 
positive externalities (and potentially negative ones as it can be interpreted 
as a vote of no confidence in the distro, discouraging others).

Believing in long term effects made Red Hat. Free software is the ultimate 
long-term investment. It's a lot of work to make software available in a form 
that may be consumed by others, without any guaranty someone will ever return 
anything useful. Yet it is successful, because together people are stronger 
than alone. Many entities that didn't understand this tried to outcompete Red 
Hat by focusing on actions with immediate returns, and skimping on long shot 
investments like sharing stuff with others. They had limited successes in 
attracting long-term customers, in building communities, in getting others to 
cooperate.

We all like to receive, but to receive you need to give first.


I can't argue with that.

What I can do is present my painful experience.

I want to use fluentd (a medium sized ruby application) + a half dozen 
or so plugins packaged as separate gems.


This puts me on the hook to be the maintainer in perpetuity of 90+ ruby 
RPM packages (for all of the build time and run time dependencies).  Not 
what I had in mind.


This wouldn't be so bad if there were some sort of automation that would 
constantly scour rubygems.org for updates and automatically update and 
build the rpms.




Regards,


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[nicolas . mailhot]

Hi Jason,

Packaging deps is a virtuous circle: it makes the work of the next person who 
needs them for other software easier, which increases the chance other software 
is packaged, which increases the value of the distro as a whole, its 
attractiveness, and the probability that someone will eventually do something 
useful for you (not limited to co-maintaining your packages). It's a long term 
virtuous investment circle.

Not packaging deps is less work in the short term, especially when you're among 
the first to arrive on an underdeveloped part of the distro, but has no 
positive externalities (and potentially negative ones as it can be interpreted 
as a vote of no confidence in the distro, discouraging others).

Believing in long term effects made Red Hat. Free software is the ultimate 
long-term investment. It's a lot of work to make software available in a form 
that may be consumed by others, without any guaranty someone will ever return 
anything useful. Yet it is successful, because together people are stronger 
than alone. Many entities that didn't understand this tried to outcompete Red 
Hat by focusing on actions with immediate returns, and skimping on long shot 
investments like sharing stuff with others. They had limited successes in 
attracting long-term customers, in building communities, in getting others to 
cooperate.

We all like to receive, but to receive you need to give first.  

Regards,

-- 
Nicolas Mailhot  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[Matthew Miller]

On Wed, Oct 25, 2017 at 06:35:36PM +0200, Vít Ondruch wrote:
> I'm waiting for your feedback basically:
> https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/HI5UZHSDQB5BRLKBXZWOC3YCND7BACGU/

Oh! Sorry! I somehow missed that. Hey Jason, can you take a look? I'm
packing up for a trip to the Freenode conference and won't be able to
for a few days.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[Vít Ondruch]

Dne 25.10.2017 v 18:10 Matthew Miller napsal(a):
> On Wed, Oct 25, 2017 at 05:56:10PM +0200, Vít Ondruch wrote:
>> You want to read this thread first:
>> https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/7ZWMVGQ3RXDWAJNP3OOZXBC57SYB5IF5/
>
> Yeah, this. :)
>
> Vit, have you made any progress?

I'm waiting for your feedback basically:

https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/HI5UZHSDQB5BRLKBXZWOC3YCND7BACGU/


V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[Matthew Miller]

On Wed, Oct 25, 2017 at 05:56:10PM +0200, Vít Ondruch wrote:
> You want to read this thread first:
> https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/7ZWMVGQ3RXDWAJNP3OOZXBC57SYB5IF5/


Yeah, this. :)

Vit, have you made any progress?

Jason, to your "is it worthwhile" question: I think we're just not ready
to move to non-RPMed things, even though I think we should get there.
We need better tooling to track the provenance and status (license,
security, etc.) of non-RPM artifacts.

Plus, I don't think containers are the whole solution here. It'd be
super-nice to be able to tell people to `yum install asciibinder` to
get started with Fedora documentation.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[Rich Megginson]

On 10/25/2017 09:49 AM, William Moreno wrote:



2017-10-25 9:38 GMT-06:00 Sandro Bonazzola >:




2017-10-25 16:54 GMT+02:00 Jason Brooks >:

Hi all --

As part of a documentation project I'm working on with the Fedora
Atomic WG, I started packaging asciibinder[1] with the
intention of
getting the package into Fedora. Along the way[2], I encountered a
bunch of required, unpackaged dependencies, which would also
have to
be added to Fedora.

[1] http://asciibinder.org/
[2]

https://copr.fedorainfracloud.org/coprs/jasonbrooks/asciibinder/packages/



It has me wondering whether packaging these gems as rpms is
worthwhile, especially since we'd end up running asciibinder in a
container, anyway.

What are people's thoughts on the value of packaging gems --
it's it
worthwhile, is it somehow UnFedora to not bother to package them?



Also consider that:

1 - your are sure that there is no broken depencies.
2 - when a new version of ruby is available those gems will be 
verified to work in next mass rebuild.

3 - all available tests as checked in every build.
4 - koshei will inform you new depencies changes.
5 - there will be stable software stack per release


Are you making these points in favor of, or against, creating rpm 
packages of gems?





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[Vít Ondruch]

You want to read this thread first:

https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/7ZWMVGQ3RXDWAJNP3OOZXBC57SYB5IF5/


Vít


Dne 25.10.2017 v 16:54 Jason Brooks napsal(a):
> Hi all --
>
> As part of a documentation project I'm working on with the Fedora
> Atomic WG, I started packaging asciibinder[1] with the intention of
> getting the package into Fedora. Along the way[2], I encountered a
> bunch of required, unpackaged dependencies, which would also have to
> be added to Fedora.
>
> [1] http://asciibinder.org/
> [2] https://copr.fedorainfracloud.org/coprs/jasonbrooks/asciibinder/packages/
>
> It has me wondering whether packaging these gems as rpms is
> worthwhile, especially since we'd end up running asciibinder in a
> container, anyway.
>
> What are people's thoughts on the value of packaging gems -- it's it
> worthwhile, is it somehow UnFedora to not bother to package them?
>
> Jason
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[William Moreno]

2017-10-25 9:38 GMT-06:00 Sandro Bonazzola :

>
>
> 2017-10-25 16:54 GMT+02:00 Jason Brooks :
>
>> Hi all --
>>
>> As part of a documentation project I'm working on with the Fedora
>> Atomic WG, I started packaging asciibinder[1] with the intention of
>> getting the package into Fedora. Along the way[2], I encountered a
>> bunch of required, unpackaged dependencies, which would also have to
>> be added to Fedora.
>>
>> [1] http://asciibinder.org/
>> [2] https://copr.fedorainfracloud.org/coprs/jasonbrooks/asciibin
>> der/packages/
>>
>> It has me wondering whether packaging these gems as rpms is
>> worthwhile, especially since we'd end up running asciibinder in a
>> container, anyway.
>>
>> What are people's thoughts on the value of packaging gems -- it's it
>> worthwhile, is it somehow UnFedora to not bother to package them?
>>
>
>
Also consider that:

1 - your are sure that there is no broken depencies.
2 - when a new version of ruby is available those gems will be verified to
work in next mass rebuild.
3 - all available tests as checked in every build.
4 - koshei will inform you new depencies changes.
5 - there will be stable software stack per release
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging ruby dependencies

[Sandro Bonazzola]

2017-10-25 16:54 GMT+02:00 Jason Brooks :

> Hi all --
>
> As part of a documentation project I'm working on with the Fedora
> Atomic WG, I started packaging asciibinder[1] with the intention of
> getting the package into Fedora. Along the way[2], I encountered a
> bunch of required, unpackaged dependencies, which would also have to
> be added to Fedora.
>
> [1] http://asciibinder.org/
> [2] https://copr.fedorainfracloud.org/coprs/jasonbrooks/
> asciibinder/packages/
>
> It has me wondering whether packaging these gems as rpms is
> worthwhile, especially since we'd end up running asciibinder in a
> container, anyway.
>
> What are people's thoughts on the value of packaging gems -- it's it
> worthwhile, is it somehow UnFedora to not bother to package them?
>

Having them packaged as RPM ensures their licenses have been checked and
binaries are built from sources.
I'm +1 for having them packaged.




>
> Jason
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

TRIED. TESTED. TRUSTED. 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

packaging ruby dependencies

[Jason Brooks]

Hi all --

As part of a documentation project I'm working on with the Fedora
Atomic WG, I started packaging asciibinder[1] with the intention of
getting the package into Fedora. Along the way[2], I encountered a
bunch of required, unpackaged dependencies, which would also have to
be added to Fedora.

[1] http://asciibinder.org/
[2] https://copr.fedorainfracloud.org/coprs/jasonbrooks/asciibinder/packages/

It has me wondering whether packaging these gems as rpms is
worthwhile, especially since we'd end up running asciibinder in a
container, anyway.

What are people's thoughts on the value of packaging gems -- it's it
worthwhile, is it somehow UnFedora to not bother to package them?

Jason
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org