Hello Samuel, Thank you for taking time in reviewing this draft.
> Do you reckon there's a specific need (eg.: it fixes certain issues) > for this release? I just wanted to keep the libewf up-to-date as much as possible, though there is no specific issue to be addressed. As you pointed out, I realised this is not always a good practice because the latest version is a pre-release, which could cause an unexpected consequence if it's packaged and distributed. Thinking again, I would like to suspend the draft package until we have a next stable release of the upstream. > There have been a couple of discussions about this in the past, you > can see them here, the consensus seems to be on the side of sticking > with the vendored libs: > https://lists.debian.org/debian-security-tools/2021/10/msg00018.html > https://lists.debian.org/debian-security-tools/2020/12/msg00012.html Apart from the draft package above, thanks for sharing the discussions in the past. Yes, it looks like their idea is to skip packaging auxiliary and support libraries if they are not used by other projects. Following this consensus, it would be reasonable for us to leave the embedded external libraries as they are. Best, Fukui On Mon, 26 Sept 2022 at 00:52, Samuel Henrique <[email protected]> wrote: > Hello Fukui, > > I was able to have a proper look at the package now, and its huge diff > between the latest release and this one (although most of it is > related to autotools). > > The packaging changes (copyright and changelog) are good, but you > forgot to push pristine-tar and upstream. > It's impossible for me to review the whole of upstream's diff due to > the autotools changes, but I did check the source diff on Github > (which was smaller). > > I then noticed that the release being packaged is marked as a > "Pre-release" and "for testing purposes". > https://github.com/libyal/libewf-legacy/releases/tag/20140814 > > Considering this, I think we need to have a good reason for picking > that release, and this includes testing the reverse dependencies to > make sure they don't break. > > Do you reckon there's a specific need (eg.: it fixes certain issues) > for this release? > > To be clear, I think it's fine (and we should) to update packages > mostly to be up-to-date with upstream, but that's as long as the > release is not marked as beta, rc, and such. When that's the case, > then we need to be more careful and confirm the need to package that > release. > In the case of libewf, if we were to go that route, we could even > consider packaging from the new repo (which is also in "experimental" > stage): > https://github.com/libyal/libewf > > Thank you for contributing! > > -- > Samuel Henrique <samueloph> >
