Store package filename in database

This would be nice to have, but maybe we can fallback to automatic generation if a filename field isn't present in the index?

I was actually thinking this topic few days ago. Originally I wanted to introduce repository management commands to apk too. But it is true that we currently have as model what Alpine does only. And it appears that more flexibility would be needed.

I think something like this could be implemented. But the main problem is how cache works currently: the automatic generated name for cached copies is different with a partial hash in the name. This is to make things work when same pkgname/pkgver/pkgrel appears in multiple repositories and is different build. There is also some places in the code that parse the filename for the package/version components to allow faster lookup from the internal structures. IIRC, this is mostly the cache format being parsed when cache purge is done.

Granted, you likely don't use cache currently. But things would need to work in both cases. Also you might want to enable caching in certain cases eventually, e.g. building of the rootfs images so same files are not downloaded several times.

I'll think this a bit more. But I think we would have use to extend the index structure so that the filename could go in some index-only structure. Should also move the PKGINFO blob's file-size there. And perhaps add another unique-id style field that also considers the package signatures (additional signatures can be amended after package generation). Basically, all the generated information of the package that might get changed later on.

mentioned in merge request !104 (closed)

mentioned in merge request !112 (closed)

changed milestone to %v3.0

For example, if I only provide a single package in multiple architectures, I could just fill a single folder with <package>-<version>-<arch>.apk instead of maintaining a variety of subfolders.

This would still not work directly.

Currently the implicit location for the index is $URL/$ARCH. And it is currently not supported to mix different architecture packages in single index. So there is still the issue of needing multiple indexes. In this case it'd likely bring more complexity to create multiple indexes with filename masks to include only wanted packages in it. But granted, apk should just also ignore the packages that are not suitable for installation based on arch.

Is there desire to have arbitrary filename / directory names that do not adhere to the package information, or would you just prefer to have an alternative or changed naming policy? I would prefer to making it a repository level feature to specify (auto detect) naming/directory policy of the packages.

In your case, if you prefer .ipk suffix, the suffix could automatically determine at least the naming policy.

mentioned in issue #10972 (closed)

After talking more about this, and considering potential other use cases. I think the plan would be to extend index format so that the index contains "package formatting specifier" which mkndx can set. It would be along the lines of $NAME-$VERSION.apk by default. And overriding this to $NAME_$VERSION_$ARCH.ipk would be another option.

This would also enable several indexes to refer to same pool of packages by having there something like ../pool/$NAME[0]/$NAME[0:3]/$NAME-$VERSION.apk.

mentioned in commit da3f91e3

mentioned in merge request !249 (merged)

mentioned in commit fce25626

mentioned in commit 7f3eed49

mentioned in commit caeec684

mentioned in commit d37f5ec4

mentioned in commit 31f72b8a

mentioned in commit 68c13965

mentioned in commit 8c39b525

closed with merge request !249 (merged)

Store package filename in database

Designs

Child items ...

Activity