[Pkg-jed-commit] r295 - in trunk/packages/jed-extra/debian: . init patches

[Jörg Sommer]

Hello G.,

G. Milde schrieb am Tue 23. May, 11:40 (+0200):
> On 22.05.06, Jörg Sommer wrote:
> 
> > Log:
> > * control:
> ...
> >   + dropped jed and xjed from the build dependencies; they are no longer
> >     needed
> 
> 
> > * patches/grep.dpatch, patches/rst.dpatch, patches/make_ini.dpatch:
> >   + these modes are buggy; hopefully upstream fixes this before release :)
> 
> If I remember right, Debian Policy (or the Maintainer Guide) strongly
> suggest cooperation with the upstream autor for fixing bugs upstream
> whenever possible. 

:) How good it is to have upstream on the mailing list. ;-)

> IMO, dpatches should be a last resort
> 
>   * if there is no response from the author in a reasonable time

Which author? The last author of the mode or jedmodes?

> IMO, a dpatch is certainly not needed to suppress a non-critical warning.    

Which warning? The source includes CVS conflict marks. That's more than
an error. And yes, I would do code cleanup like warnings, because they
are an indicator of pitfalls.

> I am happy to receive bug reports, more to receive patches (with
> explanation) but very unhappy with dpatches to my modes in a package I
> maintain - without explanation about the bug they intend to fix.

If you refer to rst.dpatch and grep.dpatch it is more than self-evidently
what's wrong there.

> > * patches/00list:
> ...
> >   + activated the patches for yodl and rfcview, because they are included
> >     in the package even if as experimental modes
> 
> the rfcview patch is also modified. I cannot easily parse the diff of a
> diff, but did you test whether the patched patch actually works?

No. I simply updated the patch in the hope it is up to date. But you are
right. The patch does not work.

Inspired by this I investigated much work in checking the modes and I
found great many missing autoload()s. See my next commit.

> > * renamed jed-extra.install.template as install
> > 
> > * contents.txt:
> >   + disabled all lines with modes not found in upstream archive -- should
> >     we remove these lines?
> 
> Please only remove lines with modes not found in jedmodes.sf.net/mode/
> (There are modes listed at Jedmodes with the sources outside the CVS
> archive.)

If I consider this file as part of the Debian package I see no reason why
we should keep track of modes not found in the orig.tar.gz.

> > * sort-modes.sl:
> >   + removed; its not needed anymore
> >
> > * rules:
> >   + all the stuff that was done in sort-mode.sl implemented directly in
> >     make with shell tools. This saves uses the dependency on jed
> 
> Actually, I would prefer to keep the sorting in SLang. It is IMO easier
> to comprehend and maintain than a bunch of make|sed|sh rules.
> 
> As jed-extra is of no use without jed anyway, the dependency doesnot pose
> a serious restriction.

I would prefer to not use a program to gernerate the config file for
dh_install at installation time. Some reasons why:

* The generated config file is a "hidden" part at build time. If one of
  the buildds ever fail in dh_install you can not reproduce why, because
  the contents of the config file is not listed in the output. What make
  does can you see.

  And I would not expect a user sends the config file with the bug report
  it build fails for him. At least, I would expect he sends the output,
  but not the config file.

* To me, it sounds really strange to call a program that generates the
  config file for a program that installs the files. Why not tell the
  installer directly what it should do? There is one stage too much, if
  you ask me.

* Why we should introduce new tool and ignore the tools already there?
  make, shell tools and debhelper are common for installation. Why ignore
  them?

* And as I said in my mail yesterday, shell tools would save a dependency
  which might save resources at the buildds and would make backporting
  much easier.

> >   + dropped the dependency from the get-orig-source target; mistake in
> >     the last commit
> 
> The idea is that the orig-source will only be fetched, if it is not
> already in place.

Why? The policy says "This target fetches the most recent version of the
original source package from a canonical archive site"

> Please remove it if you want a fresh version, maybe with a rule like
> get-fresh-orig-source.

Why you call make with the get-orig-source target if you don't want to
get the original source?

> I have to test the package also on a non-connected machine.

Me too. Where is the problem?

> >   + dropped the chmod for apsmode; its not needed anymore
> 
> Are you sure?

Yes. The tarball from yesterday did contain the files with the correct
modes.

> The Jedmodes CVS has these files in executable mode and
> every update will put them into this mode again.

Where can I send the bug report? Source Forge BTS?

Bye, Jörg.
-- 
Gienger's Law (http://www.bruhaha.de/laws.html):
Die Wichtigkeit eines Newspostings im Usenet ist reziprok zur Anzahl der
enthaltenenen, kumulierten Ausrufungszeichen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-jed-devel/attachments/20060524/844e0a2a/attachment.pgp