Como lidei com rejeições de patch após aplicar patches com uupdate?

Question

Eu usei uupdate para atualizar um pacote fonte de 0.7.0 para 0.7.3. Ele faz esta atualização com patches e eu tive algumas rejeições de patch. Eu não tenho certeza do que fazer a seguir. Eu:

• edita o pacote de origem antigo (0.7.0) e, em seguida, executa novamente o uupdate?
• edita o novo pacote de origem (0.7.3) e depois executa novamente o uupdate?
• edita os arquivos .rej diretamente?
• usa uma ferramenta como o kdiff3?
• tente outra coisa?

Neste ponto, estou pensando que a resposta é usar uma ferramenta que esteja mais de acordo com o que eu estou familiarizado (vindo de uma base de mesclagem do Tortoise Merge e do clearcase).

Eu pesquisei alto e baixo por como as pessoas gerenciam rejeições de patch e eu não tive sorte, então terei prazer em RTFM se você puder fornecer um link para um FM se existir .

    

Answer 1

Concordo com o @maco ao resolver manualmente o conflito. Vendo as opções que você dá, você provavelmente precisa realmente entender o que é uupdate does , que é:

• extrair o novo tarball no diretório pai;
• tente aplicar o diff.gz anterior (a menos que você esteja usando um estilo v3 (quilt)) no novo diretório.

As rejeições de patch vêm da aplicação deste diff.gz no novo diretório.

Agora, veja as suas opções:

• edite o pacote de origem antigo = > você não deve modificar o pacote fonte antigo para criar o novo ;
• edite o novo pacote de origem e execute novamente uupdate = > não faz sentido fazê-lo, porque o patch não se aplica à nova fonte, e você não deve modificar a fonte original (exceto com patches, que são encontrados no diff.gz) ;
• edite os arquivos .rej = > os arquivos .rej estão aqui para mostrar o que não foi aplicado; editá-los não corrigirá seu problema, mas você deve analisá-los para ver se as alterações com falha precisam ser aplicadas ;
• use uma ferramenta de comparação = > claro, isso pode ser uma boa idéia, ( vim -d é seu amigo) embora os arquivos .rej já devam dar uma idéia do que não foi aplicado. Você também pode ler o diff.gz anterior para ter uma ideia de quais arquivos ele estava modificando.

Geralmente, a maioria dos conflitos de uupdate que eu encontrei foram devidos a um empacotamento ruim na versão anterior do pacote, a saber, um diff.gz que modificou a fonte em vez de apenas adicionar um diretório debian /. Isso pode ser verificado facilmente:

zcat ../yourpackagename_0.7.0-1.diff.gz | diffstat

lhe dará a lista de arquivos modificados pelo patch anterior (adapte o nome do arquivo às suas necessidades). Se você encontrar arquivos que não estão no diretório debian / nesta lista, então seu problema certamente está lá. Nesse caso, verifique o que foi alterado:

• Na maioria dos casos, é uma bagunça automática quando debuild -S foi chamado: um dos scripts autoconf / automake foi modificado e essa modificação não será mais aplicada. Geralmente, é seguro eliminar essa alteração na nova versão;
• Em outros casos, o código-fonte foi corrigido manualmente (sem usar o dpatch / simple-patchsys / quilt / qualquer outro). Nesse caso, verifique se o patch ainda deve ser aplicado à nova versão (leia o changelog, por exemplo). Em caso afirmativo, faça um patch limpo usando um gerenciador de patches adequado. Os futuros empacotadores vão agradecer por isso: -)

Answer 2

Gostaria apenas de resolver manualmente os conflitos e executar debuild -S como de costume.