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