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

Re: Question about capstone



Hello Andew,

On Fri, 27 Dec 2024 at 04:16, Andrew Quijano <afq2003@nyu.edu> wrote:
> I wanted to ask if there is a desire to have capstone still be on the apt repositories?

Yes,

> 1. Assuming there is interest to have the apt repositories updated, could the
> maintainer just grab the packages from the releases?

Unfortunately we can't use that as the build process is not compatible with
what we do, you can see our packaging at
https://salsa.debian.org/pkg-security-team/capstone.

The build process for official packages from our repository relies on calling
dpkg-buildpackage, there's no manual manipulation of the build artifcats as you
see here
https://github.com/capstone-engine/capstone/pull/2579/files#diff-9f0be634289755e3ba4e05b5136772b6906b98dcff8112f921fc3d80ddfecbc0R57.
Debhelper takes care of everything in our build process.

> 2. Could the maintainer review the pull requests to note what would be needed
> for the Debian packages created on release to go into the official apt
> repositories?

That would never be possible as everything we ship has to be built on our own
official build-fleet from buildd.debian.org.

The closest you can get to that is to keep a copy of the "debian" folder
upstream (preferably at a different location). We keep a separation between
upstream and packaging files because we need to be able to release a new
package revision without requiring an upstream release, but the upstream and
Debian packaging can at least be kept as close as possible.

I don't know exactly your motivations, so I'm trying to be generic here.

>From Debian's POV, there's nothing wrong in upstream projects having their own
packaging methods. If you're trying to avoid duplication of work, then the only
approach which can work is to change upstream's build method to call
dpkg-buildpackage and manually sync the debian folder from time to time.

Ultimately both upstream and Debian need the freedom to perform packaging
changes without waiting for the other side to sync, but the delta can be kept
at the smallest possible with regular updates. The important aspect of this is
that there should be no assurances of the packaging being identical, there will
be Debian packaging changes that will not be applicable in the context of the
upstream project and vice-versa.

> Right now, the capstone debian package has both shared and static libraries
> in it with the header. Do we need to create two packages?

I'm not sure I understand this question, are you talking about the package from
the Debian repositories or the one from capstone upstream?

I'm cc'ing the team's mailing list (the main one used for discussions) and
Hilko, who packaged 5.0 for Debian experimental.

Hilko, were there any issues with packaging 5.0 for unstable or is that just
pending someone doing the work?

Thanks for reaching out, Andrew,

-- 
Samuel Henrique <samueloph>


Reply to: