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

Bug#995670: What's the status of this ITP?



Hi,

* Abraham Raji <work@abrahamr.in> [230620 17:37]:
> 
> On 20/06/23 13:54, Nick Hastings wrote:
> 
> > As far as I know the d/copyright file covers everything.
> > 
> > > Or is there a licensing issue here?
> > 
> > I don't think there is a licensing issue.
> > 
> > It is the specifics of the d/copyright file I produced. Please see the
> > RFS bug for details.
> 
> Will take a look. Thanks.
> 
> 
> > > I have created a zig-team namespace on salsa and I've invited you there.
> > > We can move the packaging work there as it will make it easier for
> > > potential contributors to find it.
> > 
> > I joined it.
> 
> Great let's get the zig package there.

Done.

> > > Also is there any particular reason you are only committing the debian
> > > directory?
> > 
> > That is all that exists in the repo. Builds are done by downloading the
> > source with uscan with the info from the d/watch file. I did try to look
> > into keeping upstream in the same repo but I didn't find a clear path
> > forward. So I just stuck with what I am currently doing since it works
> > and from the documentation I have read is not "incorrect". If you could
> > recommend specific documentation for this I can have a look.
> 
> I do find the ruby team's approach to be very nice here. Adding link
> to a sample ruby package for reference[0].  The approach is to keep
> the upstream files and tar ball deltas in separate branches (upstream
> and pristine-tar). The tooling makes maintaining this pretty seamless.

I see. I'll  try to have a look.

> Please take a look at these page for more information: -
> https://wiki.debian.org/SimplePackagingTutorial -
> https://wiki.abrahamraji.in/simple-packaging-tutorial.html

I'm familiar with this level of packaging.

IIRC when I tried to look at a "proper" packaging work flow using git
there did not appear to be a "correct" way to do it. Multiple different
approaches only quite briefly documented. Perhaps without much
information about why particular things were done, and seemingly to
expecting knowledge of the other approaches.

Cheers,

Nick.

> [0]: https://salsa.debian.org/ruby-team/atig


Reply to: