Conversation
| `apt.install` will install generate a package repository for each package and architecture | ||
| combination in the form of `@<TARGET_RELEASE>_<PKG_NAME>_<PKG_ARCH>`. |
There was a problem hiding this comment.
Could there be a way to specify the package version too? Regenerating the lock file currently always use the latest version but sometimes we could want older ones for compatibility.
There was a problem hiding this comment.
we support version constraints.
|
I'd find this feature very useful. I hope it gets merged soon! |
|
Still working on this, there will be some breaking changes but this will eventually land./ |
|
Hope this supports "postinst" script, or at least provides a hook for people to manually add a few commands from "postinst". |
@gfrankliu post int is just too hard to support as you must execute it within the context of a container. You're better off doing that with a dockerfile or something. |
That's why I was suggesting providing a "hook" so that people can run the equivalent postint script. Users can read/understand the package provided postinst and write a compatible/equivalent script that can run using the "hook". |
Some packages, like `krb5-multidev`, include several .so files to link
against in their pkg-config files:
```
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu/mit-krb5
includedir=${prefix}/include/mit-krb5
defccname=FILE:/tmp/krb5cc_%{uid}
defktname=FILE:/etc/krb5.keytab
defcktname=FILE:/etc/krb5/user/%{euid}/client.keytab
Name: mit-krb5
Description: An implementation of Kerberos network authentication
Version: 1.20.1
Cflags: -isystem ${includedir}
Libs: -L${libdir} -lkrb5 -lk5crypto -lcom_err
Libs.private: -lkrb5support
```
So, instead of assuming that we have one cc_library per pkgconfig file,
we just collect all the declarations and create one `cc_import` target
for each.
Some design considerations:
### Does this violate the private-ness of `Libs.private`?
All `cc_imports` we create have private visibility already, so I don't
think it does.
### Why not depend on other debian packages exporting those libraries?
Since those files are already in the package
(https://packages.debian.org/sid/amd64/krb5-multidev/filelist), I assume
the intention is to link against the `.so` files distributed in the
`krb-multidev` package, and not to pull other deb packages. This could
be false, of course, if a user has already installed those packages and
for some reason the linker finds their SO files first, but I think
that's a bug in the definition of the krb5-multidev package, not this
implementation.
Plus, it has the added benefit that, if the debian package in question
doesn't include an appropriate .so file, we just don't create the
cc_import.
6 participants
Fixes #123 #56 #66 #124