Pre-release removed without warning?

[tommilligan]

Hi, we have been using the libpff assets published here on Github as part of our build process (the same way we use a lot of other third-party tooling).

Recently we have seen a few broken builds due to releases being deleted from this Github repo. This removes the corresponding assets, causing our fetch to fail (e.g. wget https://github.com/libyal/libpff/releases/download/20231130/libpff-alpha-20231130.tar.gz)

Firstly, I just wanted to make you aware this has happened - in future we'll work around it by vendoring a version of the assets so we don't have it as an external dependency. But I also wanted to ask if there was a particular reason for removing old releases? I often find old releases and changelogs a useful resource when consuming a library. If the release is known to have issues, it would be good to know why it's been pulled.

Thanks for all your work on this project!

[joachimmetz]

But I also wanted to ask if there was a particular reason for removing old releases?

These are pre-releases per release notes Pre-release of version 20231205, for testing purposes. These are not intended as production releases.

[tommilligan]

But I also wanted to ask if there was a particular reason for removing old releases?

These are pre-releases per release notes Pre-release of version 20231205, for testing purposes. These are not intended as production releases.

That's understood, and very fair to release these versions with warnings/caveats attached. However, I don't think this is actually a reason to delete them. It's also non-obvious to me how to install the library in a more stable way than using a release (apart from cloning the repo at a specific sha) - if you have a preferred solution, I'd be happy to document it.

As I said, we've now vendored the existing pre-release version; it won't be an issue for our build in future, so I'm happy to consider this closed.

[joachimmetz]

However, I don't think this is actually a reason to delete them.

we differ of opinion here.

It's also non-obvious to me how to install the library in a more stable way than using a release (apart from cloning the repo at a specific sha) - if you have a preferred solution, I'd be happy to document it.

can you provide more context about your build process and end goal?

[tommilligan]

we differ of opinion here.

Agreed, and totally fair to run your project how you see fit :slightly_smiling_face:

can you provide more context about your build process and end goal?

I think our build is pretty vanilla; we download the sdist archive, unpack it, configure, make and install it inside a docker container we're building.

The end goal is we have a container that can run pffexport to process PST files provided by a third-party.

# Based on Ubuntu

# Download libpff source
RUN mkdir -p /tmp/libpff && \
    cd /tmp/libpff && \
    wget https://github.com/libyal/libpff/releases/download/20231130/libpff-alpha-20231130.tar.gz && \
    tar xvf libpff-alpha-20231130.tar.gz && \
    cd libpff-20231130

# Build, make and install libpff
WORKDIR /tmp/libpff/libpff-20231130
RUN ./configure --prefix=/tmp/libpff/install
RUN make && make install

---

I think, regardless of our current build process, my main confusion is that the readme/wiki pages explicitly recommend using the releases to install the library in this way:

Instead it is highly recommend to use the provided source distribution package, which contains all the necessary dependencies.

To retrieve the source distribution package go to the downloads page and download the file named:

libpff-alpha-<version>.tar.gz

Because I've been looking at this issue today, I can see that there is indeed a built Ubuntu package we could install instead for version 20180714. This is presumably the official downstream package of the libpff-experimental-20180714.tar.gz archive we used to use, so would have feature parity for us:

$ apt-get -s install pff-tools
...
Inst pff-tools (20180714-3build1 Ubuntu:22.04/jammy [amd64])

This would fit in fine with our build system, it was just not clear to me (without the discussion in this issue) that that's the preferred distribution method.

[joachimmetz]

I think, regardless of our current build process, my main confusion is that the readme/wiki pages explicitly recommend using the releases to install the library in this way

That is because

1. a lot of people using libpff know very little about compiling from source and I don't have the time to support them;
2. a source distribution package bundles all necessary scripts and dependencies.

This is presumably the official downstream package of the

This is the version Debian/Ubuntu decided to package, they retain the original source package and patches in their package management system.

This would fit in fine with our build system, it was just not clear to me (without the discussion in this issue) that that's the preferred distribution method.

I only distribute source here, not binaries, I don't have the bandwidth to support them. If the Debian/Ubuntu release works for you that might be the most straightforward.

Closing issue.