Re: Request to review and upload libewf 20140814-1

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 <samueloph@debian.org> 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>