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

[G. Milde]

On 24.05.06, Jörg Sommer wrote:
 
> > 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?

The mode author. Jedmodes is a collection of user contributed jed
extensions, the Jedmodes maintainers do not maintain the contributions
(except for the cases where these are the same person(s)). Another place for
reports to Jedmodes is the mailing list jedmodes-users at lists.sourceforge.net.

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

e.g. ***Warning: feature "foo" not found in "foo".

> The source includes CVS conflict marks. That's more than an error. 

Indeed. That is a sign of something more strange going that definitely
requires a fix upstream... (it was the result of several CVS failures
at Sourceforge lately).

> And yes, I would do code cleanup like warnings, because they
> are an indicator of pitfalls.

But please not in a dpatch.

> > 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.

I did not find it out yet.

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

"Normal" and drop-in modes must not have missing autoloads(). "Extra"
modes might require evaluation of .../utils/ini.sl. This is what Paul
Boekholt expects for his modes and it saves a lot of autoload() lines
in the code, eases maintaining and makes the modes smaller.

> > > * contents.txt:
> > 
> > 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.

For the record. There are interesting modes from other places that we
might want to add at a later point. 

Nonexisting obsolete modes (c|sh)ould be removed.
 
> > > * 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.

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

Because to me a line like 

 UTILS = $(shell sed -n -e '/^U/ {s/^.\s*//; s@\s.*@/*@; p;}' $(CONTENTS_FILE))
 
is cryptic and hard to maintain.
 

How about moving the generation of a jed-extra.install file to the
package preparation (i.e. move contents.txt and sort-modes.sl to
...packages/jed-extra/utils)? 

Rafael, what do you think?



> > 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?

To be sure it is in place. 

However, you are right -- the test would have to include a comparision of
modification times of the local copy and the version at the upstream URL
to be policy confirmant. Dropped.


> > >   + 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.

I fixed this in the working copy the tarball is made from. However, ...

> > 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?

This would require a support request to Sourceforge to change the CVS
archive. However, as I plan to move to SVN, it is not worth the effort. I
included a hack in the script that generates the tarball for the time
being.


Günter


-- 
Milde ife.et.tu-dresden.de