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

Reply via email to