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

Re: Somewhat desperate



On 2013-10-02 08:16, Joachim Zobel wrote:
> Hi.
> 

Hi,

> Now I know what to do but I find myself unable to do it. I am using the
> debian wheezy package sources from git and I can't create a patch. 
> 
> What I would do is to have the package depend on java-7 only and to
> change the ide-launcher to the attached one.
> 
> However my only option seems to be to manually edit
> debian/patches/netbeans~ide-launcher.patch. This is sure the wrong way
> to do it, but I can't get quilt/dquilt to do it.
> 

Personally, I never bothered using quilt/dquilt to handle patches for
me.  Either, I have relied on git (if already available) or done a "simple":

  $ cp $file $file.orig
  $ editor $file
  $ diff -u $file.orig $file > new.patch
  $ editor new.patch
    (add a/ and b/ plus dir to the ---/+++ lines and remove ".orig"
     from the --- line.  You can probably have diff do this for you,
     but I never bothered learning how)

Admittedly, both approaches require $file to be in its "original" state
(usually the state provided by upstream, but sometimes we have multiple
patches touching the same file).

On rare occasions I have bothered (re-)teaching myself how to get quilt
to refresh patches; but for most part I find git rebase easier to use
(and superior in its handling of changes).

But it is by no means a requirement that you use quilt (or dpatch) to
maintain the patches.  As long as you make "-p1"-strippable patches that
patch(1) can deal with, almost every "patch-system" we have will accept
it.  How you get there is up to you. :)
  If you are comfortable with git, you may want to look at some of the
"git"-packaging helpers.  I am sure we got plenty of tools here that can
turn quilt patches into a git branch (I remember using something called
"git patch queue" or so; not sure if it is still around though).

You will also find that many maintainers simply keeps their patches in
git and then have dpkg-source generate one big combined patch for them
when they build the source package.  That way they don't have to deal
with quilt at all and their changes are still separate commits in their
git repository.

> Looks like package maintenance is just not for me.
> 
> Sincerely,
> Joachim
> 
> [...]
> 


If it is just the tools confusing you, I'd recommend you try a different
approach before giving up.  I have met several tools I don't quite
"get", but that could be worked around manually with a bit of extra work
that I did understand.  "quilt"'s and "dpatch"'s patch manipulation
being some of those.
  Especially since you are (AFAICT) the only one (trying to be) active
on netbeans maintaince, I would not blink twice if you decided to change
its patch-system (or "workflow") to better suit you.

~Niels



Reply to: