[Pkg-jed-commit] r295 - in trunk/packages/jed-extra/debian: .
init patches
Jörg Sommer
joerg at alea.gnuu.de
Wed May 24 21:18:09 UTC 2006
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
More information about the Pkg-jed-devel
mailing list