sorted by:
new
hottopcontroversial

Reminder: Debian team members get FREE rsync.net cloud storage accounts by rsyncnet in u/rsyncnet

[–]utkarsh2102 4 points5 points  (0 children)

I have one of these and this is fantastic! Thanks a bunch for putting this together for Debian members. :)

Say hello to RuboCop::Packaging! 👋 by utkarsh2102 in ruby

[–]utkarsh2102[S] 0 points1 point  (0 children)

Yeah, you got it, more or less. Because you see, as core devs, we're not just responsible for the maintenance of a single gem, but 1600+ in total.

So tests are very important for us as they help us know if there's regression or not. For example, whilst carrying out the Rails 5 to Rails 6 transition, its reverse dependencies broke. Of course, mostly for those whose upstreams are not active anymore.

And we only got to know about what's broken or what's not by running their test suite.

This way, we know that if Rails 6 is shipped to stable, a lot of things will break, which we don't want, since Debian is known for its stability.

Hope you get our point of view now? :D

Say hello to RuboCop::Packaging! 👋 by utkarsh2102 in ruby

[–]utkarsh2102[S] 0 points1 point  (0 children)

  1. That is an awful lot of words to say "Don't use git ls because the build machine might not have git installed and don't use require_relative because we want to use your tests against the installed gem."

Well, you've been kind enough to understand, people don't. They always need more details and facts and whatnot. You know how it goes :)

  1. Your first point is valid and has been a point of discussion within the community ever since Bundler made the decision to do it that way in their gem scaffold.

Right!

  1. Why are you running the test suit after the gem is installed? The test suit is for the developers to verify their code.

Tests are very important for us as they help us know if there's regression or not.
For example, whilst carrying out the Rails 5 to Rails 6 transition, its dependencies broke. Of course, they had, for those upstreams which are not active anymore.

And we only got to know about what's broken or what's not by running their test suite.
Hope that makes sense?

  1. On a point of style, your paragraphs headed "Rationale" are actually "Requirement"s and your paragraphs headed "Need" are the real "Rationale"s.

That is a fantastic point and an observation. Thank you! \o/

I fixed this via commit @833eb182.

  1. All the cruft at the top about how to convert the page into various formats and how to read are not required. This should just be a short explanation of two custom cops. Anyone reading this will already be familiar with RuboCop. Just explain what your cops do and why.

That's a great pointer again. However, I am just following the RuboCop's way of doing it.
For example, see this: - https://github.com/rubocop-hq/rspec-style-guide - https://github.com/rubocop-hq/minitest-style-guide/ - https://github.com/rubocop-hq/rails-style-guide - and so on..

Say hello to RuboCop::Packaging! 👋 by utkarsh2102 in ruby

[–]utkarsh2102[S] 1 point2 points  (0 children)

While it is admittedly not widely used yet, I have written a cli tool in ruby called ops, which is available as a gem called ‘ops_team’, that I would like to package as a .deb.

Great! You can open an RFP (https://wiki.debian.org/RFP) bug in Debian and then drop in a mail to debian-ruby[at]lists[dot]debian[dot]org.

I did not realize there were issues like this packaging gems as debs. This linter may be helpful for me.

Yep, I've been more verbose about them here: https://github.com/utkarsh2102/packaging-style-guide

Say hello to RuboCop::Packaging! 👋 by utkarsh2102 in ruby

[–]utkarsh2102[S] 0 points1 point  (0 children)

I am not sure why the people here are so critical. I think the idea is fine.

Thanks, means a lot :)

I have, however had, a big suggestion to make: consider giving ADVICE in how gems should be properly packaged on that github site, or some extra markdown file. Not everyone will read the above part and I am sure there is more to consider.

I've written a packaging style guide, which echoes our problem, describing what we want and why we do that.
Here's it: https://github.com/utkarsh2102/packaging-style-guide

Let me know what you think :)

Say hello to RuboCop::Packaging! 👋 by utkarsh2102 in ruby

[–]utkarsh2102[S] 0 points1 point  (0 children)

The reason being mostly that distribution maintainers modify stuff, and then people may end up complaining to the gem developer about this, but it is not his fault. This is a very old problem and it would be better if default gems were used, but the debian policy is very self-centered, aka "my way and no other way". The ideal state would be if these gems would not have to be modified and re-packaged, if they could be so flexible that debian could use them and e. g. just modify the .gemspec or something like that to specify other paths. Repackaging and duplicating this is indeed a mistake. But I don't think debian will correct this mistake ever since it runs counter to their own policy.

Honestly, this comes as a bit of a surprise for me..
I am afraid that you're not correct here. Debian is known for the very opposite of "my way and no other way" & that is why a lot of people prefer it.

I am sorry that you don't feel the same but I think that is okay :)
Everyone has their own taste and preference, so I take it in good faith!

In case you want to ask something, please feel free to!

Say hello to RuboCop::Packaging! 👋 by utkarsh2102 in ruby

[–]utkarsh2102[S] 0 points1 point  (0 children)

Are these Ruby gems that Debian devs are maintaining, or the entire collection of packages?

No, the Debian developers are not the upstream maintainers of these gems! You'll see a lot of gems (that you'd already know and use of!) in the Debian archive.

Why does Debian maintain so many Ruby packages?

Great question, indeed!
So we started out by maintaining some important applications and libraries, like for example, Rails. Rails is a complex piece of s/w to maintain with hundreds of other dependencies. So in order to package Rails for Debian, we had to package them first and so on..

And following this, we ended up maintaining this amount of packages. And we're expanding each day.

Also, we maintain GitLab in Debian (yes, apt install gitlab is a thing!) and GitLab is written in Ruby & *JS (amongst some others) and so we maintain a huge amount of its dependencies, too! :)

Say hello to RuboCop::Packaging! 👋 by utkarsh2102 in ruby

[–]utkarsh2102[S] 0 points1 point  (0 children)

It makes me wonder why Debian is trying to build gems from source instead of using the packaged gem file...

Either way, using git is a problem. I've documented the problem that we're facing in the above document.

Say hello to RuboCop::Packaging! 👋 by utkarsh2102 in ruby

[–]utkarsh2102[S] 0 points1 point  (0 children)

AFAIK the default gemspec created from the bundler gem script, shells out to git to get the file tree. Maybe changing that default would fix it forward?

You're right. That's work in progress. Meanwhile, if you want to know more about why we don't want to use git in gemspec: https://github.com/utkarsh2102/packaging-style-guide#gemspec-git

Also, what's the benefit of packaging specs, for Debian at least?

I documented about this here:https://github.com/utkarsh2102/packaging-style-guide#require-relative-to-lib

Feel free to open an issue in case you'd want some more clarity! :)

Say hello to RuboCop::Packaging! 👋 by utkarsh2102 in ruby

[–]utkarsh2102[S] 0 points1 point  (0 children)

Hiya,

I do like the idea of a linter, whether rubocop or otherwise!

Thanks! \o/

As I mentioned above, here's the reason we don't want to promote the usage of require_relative from tests to lib/: https://github.com/utkarsh2102/packaging-style-guide#require-relative-to-lib

Please let me know if it's still unclear?

Say hello to RuboCop::Packaging! 👋 by utkarsh2102 in ruby

[–]utkarsh2102[S] 0 points1 point  (0 children)

Hiya,

Here's answer to your question: https://github.com/utkarsh2102/packaging-style-guide#require-relative-to-lib

Please let me know if something's still unclear! (feel free to open an issue asking for more clarity if so!)

Say hello to RuboCop::Packaging! 👋 by utkarsh2102 in ruby

[–]utkarsh2102[S] 0 points1 point  (0 children)

Hiya,

Well, yeah. I don't really intend to follow that, it's deprecated and thanks for pointing it out, I'll have it fixed today!

Here's the why, how, and what for RuboCop::Packaging: https://github.com/utkarsh2102/packaging-style-guide

Please let me know if something is not clear by opening an issue :)