Hi,
Le lundi 19 octobre 2020 à 10:06 +0200, Jonas Smedegaard a écrit :
> Hi Julien, and others,
>
> Quoting Julien Puydt (2020-10-19 09:15:28)
> > I was trying to update the ipywidgets package. It once had a quite
> > normal upstream, but then things went wild, if not stellar : they
> > went
> > monorepo.
> >
> > For those lucky ones who never crossed the principle, the idea is
> > to
> > have a single repository, and make dozens of different packages
> > live
> > within. Basically, different directories now are different
> > packages,
> > with different release schedules. At the moment,
> > https://github.com/jupyter-widgets/ipywidgets has 936 tags.
> >
> > There are several issues at hand :
> >
> > - uscan doesn't work correctly anymore, as the multiplication of
> > tags
> > makes them disappear in the list quite fast ;
>
> Please see uscan v4 and its version types "group" and "checksum".
I find it gives unwieldly versions when there is a lot of packages
(we're talking about a dozen packages here, with worse offenders
probably around the corner) ; and we're left with :
- an awfully long debian version string in debian/changelog ;
- need to adapt by hand the versions of the Provides: in d/control for
each sub-package.
Here is what I have in d/control for my src:lumino experiments :
Provides: node-lumino-algorithm (= 1.3.3),
node-lumino-application (= 1.11.0),
node-lumino-collections (= 1.3.3),
node-lumino-commands (= 1.11.3),
node-lumino-coreutils (= 1.5.3),
node-lumino-datagrid (= 1.14.0),
node-lumino-datastore (= 0.11.0),
node-lumino-default-theme (= 0.5.0),
node-lumino-disposable (= 1.4.3),
node-lumino-domutils (= 1.2.3),
node-lumino-dragdrop (= 1.6.4),
node-lumino-keyboard (= 1.2.3),
node-lumino-messaging (= 1.4.3),
node-lumino-polling (= 1.3.3),
node-lumino-properties (= 1.2.3),
node-lumino-signaling (= 1.4.3),
node-lumino-virtualdom (= 1.7.3),
node-lumino-widgets (= 1.14.0)
can you imagine the size of the version string in d/changelog with that
many parts?
I'm pondering writing a small Python script to print a suitable
Provides: so I'll just have to paste its output and wrap-and-sort to
update this...
> If you are already aware of that, then perhaps by "doesn't work
> correctly" you really mean "doesn't work same way as I am used to"?
>
> > - and what does one want to watch exactly anyway?
>
> Ideally we want to watch upstream releases of all upstream parts.
>
> If "upstream releases" are git commits, then watch that.
Tagged commits, yes. Sounds good, but isn't ; see below.
> If "upstream releases" are something more obscure like timestamps of
> files (yes, some do that!) then somehow watch that - or try convince
> upstream to also/instead use an easier watchable mechanism.
The situation is worse than that : a same commit can be a release for a
directory, and give something bad for another.
Imagine a project named "monorepo", with only two packages/directories
foo/ and bar/ and two tagged commits :
- 0xdeadbeef is tagged foo/3.14, and bar is broken for it ;
- 0x1337beef is tagged bar/2.72 and foo is broken for it.
How can I get uscan version 4 to do anything sane about it?
> > - even if uscan could keep up, how does one get the source? It
> > should
> > basically be a checkout of a different commit for each different
> > directory!
>
> Please see uscan v4 and its mode=git.
See above : the git mode is nice when there's a good global commit. I
don't think that assumption is going to fly.
> > - how does one even put a version number of this for a Debian
> > package?
> > (I guess something like "Provides: foo (= 3.14), bar (= 2.72)" can
> > help a little, but what about the main package?)
>
> If main package is not versioned upstream, then I would say that's a
> strong indication that you really want to track each underlying part
> as a separate Debian package instead - i.e. that upstream "main
> package" translates to a Debian metapackage.
I don't understand what you mean here. A src:monorepo-something for
each? With adapted d/copyright Files-Excluded: to get only the right
directory?
Even in that case, will uscan see the tag subpackage42/3.14 on github?
In my experience, it only sees a handful of last tags, so it will see
the releases of something like subpackage1/* to subpackage23/*, but not
the other ones. For example, it doesn't see the last ipywidgets release
7.5.1's tag, so I had to download it by hand before calling gbp import-
orig.
> > PS: and to package the next ipywidgets, I started to work on lumino
> > (
> > https://github.com/jupyterlab/lumino) with the same problem. In my
> > experiments I numbered the main package 0~20200824+git93880412-
> > 1...
> > which is not ideal.
>
> Why is that not ideal?
It is not ideal because :
(1) I've just been lucky : they have tagged different commits for the
stable releases, but didn't break anything in-between, so I'm packaging
something stable for each subpackage ; as pointed above, that might not
always be the case ;
(2) my experimental package claims to ship node-lumino-widgets (=
1.14.0), but that is incorrect, since I'm basing my src:lumino on git
commit 938804120f58bf61e795bde9d596f6ce7573e920, while that release is
really on git commit 443967554e00d43a42f989157c5185b83bccab09 !
> I would drop the git part as it cannot be sorted (there is no
> guarantee
> that next git commit on same day leads to a higher version number).
> I.e. use 0~20200824-1 and if you come across needing to issue a
> second release on same day then use 0~20200824.1-1 for that.
I know I can do that ; but I wanted the (start of) the commit hash to
appear, because since it's a made-by-hand orig source tarball, it needs
proper documenting. There's a debian/README.source too, to explain
exactly what I removed from the git checkout too. Any DD will be able
to verify and replicate my work -- that's important if I get under a
car or anything.
> You might find some inspiration in the source package
> jsbundle-web-interfaces which uses version type "group" and
> mode=git, and sets individual version numbers for each binary
> package.
Only four subpackages, and it's the reverse of a monorepo : it's
fusioning different git repositories in a single src:foo. It doesn't
have versioned Provides: in d/control.
> Another example is matrix-mirage where one component is fixed at a
> specific release.
Same as above (with only two subpackages).
I have the feeling I haven't been crystal clear in my question, since I
ended up with examples of just the reverse situation as answer.
I hope I did better this time : how to get a single tarball from a
single repo but several commits?
Thanks,
JP
