Thanks to all who answered my questions.
So, to summarize (and ensure I understood all answers correctly):
- For packages which don't have intermediate files (things that don't
need to be built, like scripts, static data, configuration files, or
whatever), it's perfectly fine to have a single ups
Charles Plessy writes:
> If you do this and intend to make your source package's repository easy to use
> for collaborative maintenance, it will be good to document this workflow
> somewhere (perhaps README.source ?) since it is not standard.
Agreed. If getting a ready-to-modify-then-build worki
Le Thu, Apr 07, 2016 at 03:25:08PM +0200, Raphaël Halimi a écrit :
>
> If I understand [1] and [2] correctly, one would need two upstream
> branches : one originating from upstream, with the full commit history,
> and one managed by gbp import-orig, which would contain upstream sources
> imported
Raphaël Halimi writes:
> I'm trying to fully understand the git-buildpackage workflow and I'm
> kind of stuck on a specific part of the process, regarding the handling
> of the upstream branch when upstream uses git but the maintainer still
> wants to use pristine-tar to commit upstream tarballs.
Hi,
FYI borgbackup is following that style.
cheers,
G.
Il Giovedì 7 Aprile 2016 17:49, Sean Whitton ha
scritto:
Hello,
On Thu, Apr 07, 2016 at 03:25:08PM +0200, Raphaël Halimi wrote:
> I'm not sure if this question belongs to -mentors or -devel, so I'll
> post it here at first, feel free
Hello,
On Thu, Apr 07, 2016 at 03:25:08PM +0200, Raphaël Halimi wrote:
> I'm not sure if this question belongs to -mentors or -devel, so I'll
> post it here at first, feel free to relocate/cc if you think it's
> appropriate.
-mentors is fine.
> I'm trying to fully understand the git-buildpackage
6 matches
Mail list logo
