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

Re: Patching apt-cacher-ng (Was: Documenting the generation of the live images in Debian)

On 21/03/2020 18:53, Eduard Bloch wrote:

>> In reply to the patch at https://bugs.debian.org/954437

> I cannot accept your patch as-is. Because it's brute-force, a directory
> is not neccessarily a non-volatile file. Can you give me any hints how
> to distinguish between volatile and non-volatile directories? Maybe the
> same as it's done for for other d-i files, by regex, so
> 		"|/dists/.*/installer-[^/]+/[0-9][^/]+/images/.*" // d-i stuff with revision
> means frozen contents and
> 		"|/dists/.*/installer-[^/]+/[^0-9][^/]+/images/.*" // d-i stuff but not containing a date (year number) in the revision directory (like "current", "beta", ...)
> is volatile? (those regexps are already defined, I just need to change
> your patch to make them applicable to directories)

Agreed. The patch is a brute-force hack, but at least it allowed me to
build my first CD unofficial images.

After I've written my summary to the list, I dug deeper into
live-wrapper. It uses either the released installer (using the apt
proxy), which doesn't contain versioning information in the path, but
will most probably be rather non-volatile, from
or the daily build directly (without apt proxy) from

However, I currently think that my issue is located within the
live-wrapper package. lwr performs a download which isn't used. In
lwr/utils.py the line check_url(base_url) should be removed. Then I
wouldn't need a patched version of apt-cacher-ng at all...

> Also, what's your deadline? I was planing to release a new version of
> ACNG in a couple of days anyway. Do you also need it in backports?

If you still would like to include the patch, I think that the content
listing of a directory should always be considered volatile.

But, as said, I think that the bug should be reassigned to the
live-wrapper package.

With kind regards,
Roland Clobus

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: