Re:The state of the art with the current ruby-aws-sdk packaging versions (was ruby-aws-sdk_2.11.422-1_amd64.changes REJECTED)
On 2020, ജനുവരി 13 12:00:38 AM IST, "David Suárez" <david.sephirot@gmail.com> wrote:
>Correct me if I'm wrong... But going this way, will not getting worst
>the current state we have with this package, with binary|sources
>packages duplicates ?
>
>Now's we have:
>
>- ruby-aws-sdk (v1):
>
> + Pulled from github, so it has src:ruby-aws-sdk:v1
> + it contains all the services that the libraries provides.
>
>- ruby-aws-sdk (v2):
>
> + In experimental (current version pulled from gem), so is
>src:ruby-aws-sdk:v2 (duplicate src package, from same sources)
> + Is broken
> + It cannot enter unstable, because v3 has the binary package
>ruby-aws-sdk-core with higher version number
>
>
>- ruby-aws-sdk (v3):
>
> + In testing/experimental, each binary package (ruby-aws-sdk-s3,
>ruby-aws-sdk-kms, ruby-aws-sdk-core, ruby-aws-partitions) pulled from
>gem.
> + From a point of a debian user, it completes unusable, because only
>export the s3 service.
I think you are still not understanding the reason for v3. I don't think any user will use aws-sdk directly with v3 but only the services they actually need.
For example, gitlab was using aws-sdk v2 but only need aws-sdk-core and aws-sdk-cloudformation. People were forced to use entire aws-sdk because they did not have a choice of selecting the services they need.
Same happened with fog as well. We did not package every sub module of fog, but only the ones we require.
>
>Seeing this, we have, from the same set of sources (diferents
>versions),
>6 sources packages. And lots of binaries packages (some of them
>duplicates).
>
>
>
>If v3 will be needed for loomio, why not package it for unstable,
>testing ... But putting all the gems, so it could replace the v1
>packaging without losing any amazon service ? With the current v3
>packaging, we cannot drop the v1 version that is deprecated, because
>they only provides s3 lib. (and v2 version in the current state can't
>enter unstable).
Thinking of packaging all of the services is like thinking of packaging every rubygem published on Rubygems.org.
>
>
> From my point of view packaging all the v3 gems could not be lot's of
>work, if we use the multi binary layout that gem2deb provides.
I'm just saying it is unnecessary.
>Using multibinary layout and github sources, have the advantanges that:
> - We don't have multiple source packages
> - each with the same debian/copyright
> - the same debian/upstream/metadata
> - and so on...
>
>We only have todo:
>
> - Import the package from the sources (not gems)
> - For each gem in the 'gems' dir, we have only add an entry in
>debian/control declaring the binary package (example here [0]).
>
>This last work could be automated with a ruby script, so passing this
>script some dir as input (or list of gemspec), it will add in
>debian/control the needed info for the binary package (each gemspec or
>dir will generate a binary pacakge).
>
>Well, it haves to take into account that:
> - a gem could be new (all the stanzas in debian/control for this
>binary package have to be added)
> - updated (only dependencies have to be updated)
> - or deleted from.
>
>This script later could be reused for other ruby libraries packaging.
>
>
>Talking about importing debian packages from gems (maybe I have to open
>
>a thread for the debian ruby team members take into account), from my
>understand, is not the natural way of working, because:
>
>- a gem is a binary artifact produces by the build of the ruby library
>sources
> - a gem not contains any useful files like: tests, docs, etc (that's
>why, lot's of packages in ruby group are pulled from github or other
>scm's)
> - Importing from gem allow's the current disaster that we have with
>this library. lots of sources|binaries packages that are
>constructed|downloaded from the original repository sources or
>artifacts
>built by them (aka gem files).
>
>
>In summary:
>
>Renaming the packages to v2 is not the way to go, and will produces
>lots
>of duplicates, making endusers and ruby developers that want to consume
>
>this lib, very dizzy.
>
>If v3, is the preferred version because of loomio packaging, then it
>should provides all the services provided by v1 version. This way it
>could replace v1, without breaking any enduser.
>
>
>Any complains, improvements, suggestions are accepted...
My suggestion. Use github tar for source, but build only the binaries for services we actually use (for gitlab, loomio and in future based on user request). But if you really insist on packaging all the services, you can go ahead and do it. For gitlab, the merge request is already approved so we can take that patch and use aws-sdk v3.
If at all we need the whole aws-sdk (I don't think anyone will need it), then create aws-sdk-v2 for that use case.
>
>Thanks,
>
>--
>
> David
>
>
>[0]
><https://salsa.debian.org/ruby-team/ruby-aws-sdk/blob/master/debian/control>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply to: