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)
Hi,
CC'ing Utkarsh, thats could be interested.
On 12/1/20 5:45, Pirate Praveen wrote:
On 2020, ജനുവരി 12 1:53:56 AM IST, "David Suárez" <david.sephirot@gmail.com> wrote:
Could you try again?. The upload goes now for experimental until
duplicates packages of v3 of this same gem gets ROM.
I will request ROM for:
- ruby-aws-sdk-s3
- ruby-aws-sdk-core
- ruby-aws-sdk-kms
The motive is, that this packaging have to go as submodules of the root
package ruby-aws-sdk. And they are the version 3 of 'ruby-aws-sdk' that
like you suggested, they are not needed for gitlab.So for ruby-aws-sdk
(version 2), the current ruby-aws-sdk-core and ruby-aws-sdk-s3 have
higher versions.
This way we can't offer the v3 versions of all services, because the
neededs gems didn't get packaged atm (if we want to package v3, I think
that we should package all the services gems, not a pair of them).
Can we add -v2 to 2.x packages ? ruby-aws-sdk-v2, ruby-aws-sdk-core-v2 etc? I think the v3 gems were packaged for loomio so we can't just remove them (loomio is still not complete, but its not nice to just remove other people's work). And the idea of v3 is to depend only on the services you need instead of whole SDK. It will take some time for gitlab to move to v3. Once gitlab moves to v3, we can ROM -v2 packages.
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.
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).
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.
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...
Thanks,
--
David
[0]
<https://salsa.debian.org/ruby-team/ruby-aws-sdk/blob/master/debian/control>
Reply to: