[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: supernovas upstream update -- needs sponsor



Hey, Hey!

Alright, so after discussion it was concluded that using !cross would make the
package not reproducible[1] and that we should instead use some package specific
build profile. So I went ahead with "pkg.supernovas.ciodata" and mentioned about
it in d/README.Source, if in case someone wants to crossbuild it.

Also passed in that build profile in salsa ci file so the CI keeps passing. It
isn't the best solution but a fair compromise.

I also evaluated the feasibility of adding in a "Suggests" in libsupernova1 for
the 2 other library, but if someone runs these with --install-suggests, I am not
sure if the sort of circular dependency that created here and if it could become
unresolvable. So I skipped doing so for now -- I am not aware about how apt would
internally react to it. Could try once to check.

We can add it in the subsequent upload if desired for sure.

I have uploaded the package for now. It was a nice experience working with you!

[1]: https://wiki.debian.org/ReproducibleBuilds

Best,
Nilesh

On Sun, Jun 02, 2024 at 07:47:31PM +0200, Attila Kovacs wrote:
> Hi Nilesh,
> 
> 
> Thanks a lot for all the good work you put into this. I really, really
> appreciate it.
> 
>  I must admit Debian packaging is quite overwhelming for a noob -- much more
> so than Fedora's. It's also less forgiving, and cumbersome (I found working
> with the patch queue especially annoying). And the relevant documentation
> tends to be quite scattered, and some of the documents can be at odds with
> one another (e.g. 'gbp import-orig' vs 'uupdate', not to mention the 'uscan'
> command you ended up using in the end)... On the good side, I did find the
> Debian package checking more thorough and helpful than Fedora's, and it
> helped catch a bunch of issues even before it landed on your desk... And
> best of all it's great to have experience people like you help out, and get
> things done right.
> 
> Hopefully, my next packages will go more smoothly. (I'm planning to
> open-source a few more libraries over the next year or so, and will try to
> package them also).
> 
> I owe you one!
> 
> cheers,
> 
> -- A.
> 
> 
> On 6/2/24 7:33 PM, Nilesh Patra wrote:
> > Hi Attila,
> > 
> > On Sun, Jun 02, 2024 at 06:36:18PM +0200, Attila Kovacs wrote:
> > > Thanks Nilesh for cleaning things up nicely, and for offering to sponsor it.
> > > I'll gladly accept your offer!
> > > 
> > > 
> > > I'm generally OK with the renaming to follow the library style guide. I do
> > > find it a little particular (and awkward) though for two reasons:
> > > 
> > >   1. the libsolsys1-1, and libsossys2-1 are somewhat awkward although if that
> > > is the standard for naming packaghed libs that have a number as part of
> > > their name, then it is what it is.
> > In general packages should match the name of the so that they provide unless you
> > have a very good reason not to. The .so in them are libsolsys1.so.1 and
> > libsolsys2.so.1 and hence the names.
> > 
> > Maybe it'd make sense to rename .so files to something else as upstream?
> > Not sure, but it does not look like a big concern.
> > 
> > >   2. For libsolsys1-1 and libsolsys2-1, the package names hide that these
> > > belong to the supernovas package (that they are optional packages thereof).
> > > I guess that's OK, since the dependencies are there. Perhaps you could add a
> > > 'Suggests' to libsupernovas1, so  they are more easily discoverable by users
> > > who might be wondering what packages might provide the legacy
> > > functionalities...
> > Fine, can do.
> > 
> > > I'm curious, how did you manage to import the upstream with the same version
> > > '1.0.1-2'? I have utterly failed doing that even though I wasted a full day
> > > trying as I might. :-)
> > I was pretty easy after fixing d/watch and removing the annoying uupdate.
> > 
> > 	$ uscan -dd --verbose --download-version 1.0.1-2
> > 
> > worked.
> > 
> > > Finally, I noticed you removed the version dependence on doxygen. Maybe
> > > that's OK, but the fact is that older versions of doxygen will caugh up an
> > > error with the Doxyfile configuration, as it contains settings that are not
> > > supported in earlier releases of doxygen. (If you do change your mind on
> > > specifying a minimum version, you probably want it to be the current one,
> > > which is 1.10, I think).
> > It was some automated tooling (cme) that did so. The uploads to packages go
> > through unstable and are built with packages in unstable. Sometimes you want to
> > backport things to stable, and very rarely to old-stable. Debian versions before
> > that are mostly unsupported.
> > 
> > The version of doxygen in even old stable is 1.9.1 so the version dep is not
> > needed as such. Keeping it does not hurt, sure but there's no utility per se.
> > 
> > There's some confusion going on on whether to use !cross profile or not and I'm
> > talking to people in #debian-bootstrap. Once that's closed, I'll make the change
> > for cross builds, add a suggests on libsupernovas1 for libsolsys* and upload to
> > the NEW queue. It will then be reviewed by the FTP masters before accepting it
> > into the archive.
> > 
> > Best,
> > Nilesh
Best,
Nilesh

Attachment: signature.asc
Description: PGP signature


Reply to: