The index file generated during the package build is considered invalid by “--list-index-packages”. The reason is that the code behind the latter expects a path segment before the package filename in the index (e.g. “foo/bar_1.2….ctrl”). Commenting out the responsible code in wpkgar_repository::load_index makes it work, but I'm not sure what is considered supported. Should repositories with packages in the base (“.” as the last component in the source specification) directory be supported?
Hmmm... I guess I never checked that index file before.
However, the index file, to work properly with the --update / --upgrade and other such commands needs to have a directory tree. This is because the upgrade will not allow you to get a .deb from the root directory.
So I guess the creation should fail in this case, or at least not add any .deb from the root directory (which in this case would mean an empty index file and thus a failure.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, I applied a fix which prevents you from creating an index (i.e. the --create-index option) file that has .deb files in the root directory. Actually, at this time it creates an error which means that you cannot have such files in the root directory at all. We could change that to a warning only, but thinking about it, it may be "dangerous" because some people may think that this is legal when it isn't.
My change is checked in.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm fine with not having packages at the root. Not that I have much of a choice. :-)
However, if I read [1] correctly the index must still support .deb archives in the same directory as the index. When a component is given (e.g. “main”) wpkg will fetch the index from that component's directory.
$ cat …/var/lib/wpkg/core/sources.list
wpkg …/wpkg-repo . main
$ find wpkg-repo -type f | sort
wpkg-repo/index.tar.gz
wpkg-repo/main/wpkg_1.0.1_linux-amd64.deb
wpkg-repo/main/wpkg-dev_1.0.1_linux-amd64.deb
wpkg-repo/main/wpkg-doc_1.0.1_all.deb
wpkg-repo/main/wpkg-hdrs-dev_1.0.1_all.deb
$ …/bin/wpkg --root …/root --update
failed updating index file from repository: "…/wpkg-repo/./main/index.tar.gz". (repository)
With your change one can't generate that requested per-component index anymore, “an index filename always expects at least one path segment before a package name”. Everything works as expected when I don't specify a component.
Should the verification be done by the client when updating source indices? With my current understanding of wpkg that's the earliest place where we know that a component name is in use.
Also, by putting in this error, it breaks backward compatibility (even
if it's wrong according to the standard). I have an idea--let's put in a
backward-compatible mode that will allow the old behavior. This could be
marshaled to the library code via a switch in wpkg, and an option in
pkg-explorer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, yes! Since you have that special case with the distribution name ending with a slash, we have support names without a path. I fixed the --list-index-packages command to not generate an error when no path is found.
Sorry for the troubles caused.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello
The index file generated during the package build is considered invalid by “--list-index-packages”. The reason is that the code behind the latter expects a path segment before the package filename in the index (e.g. “foo/bar_1.2….ctrl”). Commenting out the responsible code in
wpkgar_repository::load_index
makes it work, but I'm not sure what is considered supported. Should repositories with packages in the base (“.” as the last component in the source specification) directory be supported?Patch for reproduction:
Hmmm... I guess I never checked that index file before.
However, the index file, to work properly with the --update / --upgrade and other such commands needs to have a directory tree. This is because the upgrade will not allow you to get a .deb from the root directory.
So I guess the creation should fail in this case, or at least not add any .deb from the root directory (which in this case would mean an empty index file and thus a failure.)
Okay, I applied a fix which prevents you from creating an index (i.e. the --create-index option) file that has .deb files in the root directory. Actually, at this time it creates an error which means that you cannot have such files in the root directory at all. We could change that to a warning only, but thinking about it, it may be "dangerous" because some people may think that this is legal when it isn't.
My change is checked in.
I'm fine with not having packages at the root. Not that I have much of a choice. :-)
However, if I read [1] correctly the index must still support .deb archives in the same directory as the index. When a component is given (e.g. “main”) wpkg will fetch the index from that component's directory.
With your change one can't generate that requested per-component index anymore, “an index filename always expects at least one path segment before a package name”. Everything works as expected when I don't specify a component.
Should the verification be done by the client when updating source indices? With my current understanding of wpkg that's the earliest place where we know that a component name is in use.
[1] http://windowspackager.org/documentation/implementation-details/file-formats/sourceslist-file-format
Also, by putting in this error, it breaks backward compatibility (even
if it's wrong according to the standard). I have an idea--let's put in a
backward-compatible mode that will allow the old behavior. This could be
marshaled to the library code via a switch in wpkg, and an option in
pkg-explorer.
Okay, yes! Since you have that special case with the distribution name ending with a slash, we have support names without a path. I fixed the
--list-index-packages
command to not generate an error when no path is found.Sorry for the troubles caused.
Thank you. This appears to be a non-issue as of revision
2ebf7b3
.