Re: CDBS and dh_install

[George Danchev]

On Wednesday 14 June 2006 03:58, Manoj Srivastava wrote:
> On 13 Jun 2006, George Danchev said:
> > On Saturday 10 June 2006 15:57, Marc Dequènes wrote:
> > --cut--
> >
> >> Until this is solved, i'm still maintaining my original version,
> >> since more people use it than the one in the package, but this is
> >> not an ideal situation.
> >
> > Ok, time to ask a real question about cdbs ;-) I assume you are
> > pretty much familiar with it and its strengths and weaknesses, hence
> > my little problem follows:
> >
> > my debian/rules (in which I have my self-written target, no it is
> > not supported by cdbs yet)
>
> I do not think your make file does what you think it does. It
>  replaces, instead of enhancing, the single colon rule that CDBS
>  uses.

Absolutely right. This has nothing to do with CDBS features, the fault 
is 
mine.

> > * what couses that, and how to escape that annoying warn ?
>
> common-configure-arch common-configure-indep:: myowntarget
>
> myowntarget:
> ./configure --prefix=/usr
> touch debian/stamp-autotools-files

I really failed to suspect the single/double colon dependencies! In 
fact, in 
my second thoughts and after digging for a while into rules and class CDBS 
makefiles I realized that it is enough to have just debhelper.mk and 
autotools.mk included in my debian/rules file and have all the common things 
I need. Then I added my own and unique (phony) targets to enhance what I 
already have inherited from cdbs. That is what I think I need - the common 
things should be implemented by a common pile of code, and my part stays 
really mine, isolated and being added next to that.

Thanks for the comprehensive make lecture, it was pretty refreshing, at 
least 
for me.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Manoj Srivastava]

On 13 Jun 2006, George Danchev said:

> On Saturday 10 June 2006 15:57, Marc Dequènes wrote:
> --cut--
>> Until this is solved, i'm still maintaining my original version,
>> since more people use it than the one in the package, but this is
>> not an ideal situation.
>
> Ok, time to ask a real question about cdbs ;-) I assume you are
> pretty much familiar with it and its strengths and weaknesses, hence
> my little problem follows:
>
> my debian/rules (in which I have my self-written target, no it is
> not supported by cdbs yet)

I do not think your make file does what you think it does. It
 replaces, instead of enhancing, the single colon rule that CDBS
 uses.  

> * what couses that, and how to escape that annoying warn ?


common-configure-arch common-configure-indep:: myowntarget

myowntarget:
./configure --prefix=/usr
touch debian/stamp-autotools-files

> * where is that described in cdbs official or unofficial docs ?

Err, if you look at the warning, you see where it comes
 from. Looking at the target, you can see  that
 debian/stamp-autotools-files is a double colon dependency of  targets
 common-configure-arch and common-configure-indep. So, it is simple as
 to how one introduces the additional commands ...

> Thanks. Excuse moa if I failed to see the obvious ;-)

There is a difference between double colon dependencies and
 single colon dependencies. You'll be well served to know the
 difference.

manoj

==
One file can be the target of several rules.  All the prerequisites
mentioned in all the rules are merged into one list of prerequisites for
the target.  If the target is older than any prerequisite from any rule,
the commands are executed.

   There can only be one set of commands to be executed for a file.  If
more than one rule gives commands for the same file, `make' uses the
last set given and prints an error message.  (As a special case, if the
file's name begins with a dot, no error message is printed.  This odd
behavior is only for compatibility with other implementations of
`make'... you should avoid using it).  Occasionally it is useful to
have the same target invoke multiple commands which are defined in
different parts of your makefile; you can use "double-colon rules"
(*note Double-Colon::) for this.


"Double-colon" rules are rules written with `::' instead of `:' after
the target names.  They are handled differently from ordinary rules
when the same target appears in more than one rule.

   When a target appears in multiple rules, all the rules must be the
same type: all ordinary, or all double-colon.  If they are
double-colon, each of them is independent of the others.  Each
double-colon rule's commands are executed if the target is older than
any prerequisites of that rule.  If there are no prerequisites for that
rule, its commands are always executed (even if the target already
exists).  This can result in executing none, any, or all of the
double-colon rules.

   Double-colon rules with the same target are in fact completely
separate from one another.  Each double-colon rule is processed
individually, just as rules with different targets are processed.

   The double-colon rules for a target are executed in the order they
appear in the makefile.  However, the cases where double-colon rules
really make sense are those where the order of executing the commands
would not matter.

==

-- 
You will get what you deserve.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[George Danchev]

On Saturday 10 June 2006 15:57, Marc Dequènes wrote:
--cut--
> Until this is solved, i'm still maintaining my original version, since
> more people use it than the one in the package, but this is not an ideal
> situation.

Ok, time to ask a real question about cdbs ;-) I assume you are pretty much 
familiar with it and its strengths and weaknesses, hence my little problem 
follows:

my debian/rules 
(in which I have my self-written target, no it is not supported by cdbs yet)

#!/usr/bin/make -f

DEB_DH_INSTALL_SOURCEDIR=debian/tmp

include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk

DEB_CONFIGURE_PREFIX=/usr
DEB_CONFIGURE_SYSCONFDIR=/etc
#DEB_CONFIGURE_EXTRA_FLAGS := --prefix=/usr

debian/stamp-autotools-files:
./configure --prefix=/usr
touch debian/stamp-autotools-files

myowntarget: 
here... 


Then if I execute my target a possbily harmless warning follows:

$fakeroot debian/rules myowntarget
debian/rules:13: warning: overriding commands for target 
`debian/stamp-autotools-files'
/usr/share/cdbs/1/class/autotools-files.mk:54: warning: ignoring old commands 
for target `debian/stamp-autotools-files'
Upstream source tarball have been already downloaded
Upstream filename md5sum is trusted!


My questions are: 
* what couses that, and how to escape that annoying warn ?
* where is that described in cdbs official or unofficial docs ?

Thanks. Excuse moa if I failed to see the obvious ;-)

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Eduard Bloch]

#include 
* Marc Dequènes [Sun, Jun 11 2006, 03:00:12AM]:

> > and replace it with a very small shell script.  For cdbs, you delete one
> > line and have to replace it with your reimplementation of a very large
> > makefile...
> 
> That's obvious because CDBS does not target at doing little independent
> tasks (even if some may be *perhaps* be transformed to dh_*), but to
> autogenerate rules. CDBS is a layer over debhelper, this cannot be
> simply compared this way.

Yes. And you rely completely on CDBS doing some automagick and do the
right thing. But... oh wonder, somehow most of my packages do not fit
into this pattern of "./configure && make && make install && PARTY!".

> > Oh, I disagree; I think I have a pretty good idea what the benefits are of
> > CDBS, I just think that many CDBS proponents underemphasize the *downside*
> > of CDBS.
> 
> That's not true for everybody. The auto control generation is now never
> run automatically because we agreed it could cause harm.

Why could you, oh why? you do not trust the God Of Autoscripting any
more? You bastards1

> You simply don't care about this...

And when I _need_ to care about this because sth. does not work?

> If something is missing or inadéquate you juste hook on makefile rules
> and add your own commands (debhelper if necessary). you can even stop

"Just Hook", aha. You can say that if you know all the variables and the
internal dependencies.

> including some classes and reimplement what is uncommon and thus has no
> reason to be in a class. I never found any package being fully uncommon,
> so i see no reason not to use CDBS if you feel well with this tool with
> any package..
> 
> If the packager has no time to learn Debian tools correctly, then he

There are tools, and there are tools. Debhelper tools are usualy easy to
understand (at least what they exactly do) and to work around in case of
failure, but CDBS is a complex code hell.

> must not be sent to NM, or must not be accepted by AM or DAM, that's
> really obvious. People willing to have a @debian.org email for fun or
> unwilling to learn and work seriously can just can become MOTUs...
> What would you say if i told you i had not yet time to learn how the
> BTS work because my level of committment is not high enough and that i
> won't be able to manage my bugs until 6 more months ?
> 
> Sometimes i really don't understand you...

Because most pro-CDBS opinions here are from people dealing only with
"very standard" packaging cases and refuse to try to see things from
another POV. And don't accuse me of not understanding the issue or
similar crap. I created module-assistant includes for similar purposes a
while ago but I always cared about creating more benefits where they are
required without enchaining maintainers.

OTOH I am pissed, CDBS folks are using a var with conflicting name (and
module-assistant have been first with using it, I am not going to rename
the var), I sent my complaint to their ML and nothing happened. Now you
get a bug report.

And about "easy to extend"... I just looked trough the current manual
since someone told the docs have been improved. I still don't have a
single idea how can I easily put a certain custom tool call between
other debhelper commands.

> The documentation is still work in progress and is actively improved
> over time, just be patient *or* help.

Ehm, ok. But those docs are about internals, CDBS' developers should
know best how they work and be able to describe them best.

> > The flip side of this is that the behavior of cdbs-using packages is always
> > changing, without the knowledge or control of the package maintainer.  E.g.,
> > while I was drafting this message,
> >  showed up
> > in my mailbox...
> 
> In the past some mistakes were done in debhelper too, even if i don't
> recall a specific case to mention. That's not often this happen to CDBS,
> but i agree this should be avoided, that's why i'd like Peter to finaly
> accept co-maintainership.

Peter? Which Peter? Whoever, that is not about "mistakes happened there
to". With CDBS, a such bug IN CDBS means failure with working around it
becoming PITA.

> > No, clearly makefile includes shouldn't have manpages; but some kind of
> > documentation that tells cdbs users what they should or shouldn't be able to
> > depend on would be a good idea.  In the absence of such documentation I
> > think the current answer to what they can depend on is actually "very
> > little", which is a big part of why I don't encourage its use.
> 
> A documentation do exist, even if you seem to be completely blind and
> features which are described are behaviors you can count on. When a

Who is blind? Reread his text please. What about things you should
avoid, where are those documented?

> feature has changed for very important reasons like the control auto
> generation one, a warning is displayed (so you know you cannot count on
> it). Undocume

Re: CDBS and dh_install

[Duck]

Mike Hommey <[EMAIL PROTECTED]> writes:

> Probably because a change in debhelper is done with a change of
> compatibility level. And you still can use the old behaviour by using
> the appropriate level.

I was talking about mistakes, and package care, and package reviewed by
several persons of a team so as to avoid this situation, and you're
talking about planned major feature changes. You're out of topic.

-- 
Marc Dequènes (Duck)


pgp1nwqwLKqBL.pgp
Description: PGP signature

Re: CDBS and dh_install

[Duck]

Mike Hommey <[EMAIL PROTECTED]> writes:

> Probably because a change in debhelper is done with a change of
> compatibility level. And you still can use the old behaviour by using
> the appropriate level.

I was talking about mistakes, and package care, and package reviewed by
several persons of a team so as to avoid this situation, and you're
talking about planned major feature changes. You're out of topic.

-- 
Marc Dequènes (Duck)


pgpPDJSYpppnV.pgp
Description: PGP signature

Re: CDBS and dh_install

[martin f krafft]

also sprach Jean Parpaillon <[EMAIL PROTECTED]> [2006.06.12.0931 +0200]:
> Uhhh,
> I did not want to launch such a big discussion :-)

Then you should not have written to debian-devel. :)

> - I first used a simple "rules" script, because I can not imagine
> using a wrapper while not knowing the system it is around.
> - But now, I use CDBS because it is much simpler to follow the
> policies with it, and to have "good practices", ie using
> *.install, *.dirs, etc. files.

Those files are debhelper files; you don't need to use CDBS to use
them.

> To conclude, I will use CDBS because :
> - I know how to write a package without it
> - and there are no hacks in the packaging.

Fine. Your choice. Hopefully I never have to step in to help out
with your package.



also sprach Tollef Fog Heen <[EMAIL PROTECTED]> [2006.06.12.1051 +0200]:
> > Is Debhelper our C and CDBS our C++?
> 
> CDBS is to debhelper as XSLT (or prolog) is to C (or another procedural 
> language).

Rght.


also sprach Christoph Berg <[EMAIL PROTECTED]> [2006.06.12.1138 +0200]:
> Not in that length. The template question used by most AMs is:
> 
>   Write a small shell script which does the following two things: 
>  a. prints whether a Debian package archive file has a copyright file
> in the appropriate location.
>  b. prints out the package version from the control file which is
> inside the .deb.
>  You may use tar, ar, grep, etc., but not any middle or high-level
>  dpkg tools.

Neither of these tests show whether the candidate can build a source
package without helpers.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"the 'volatile' keyword
 is implemented syntactically
 but not semantically"
  -- documentation of m$ visual c, around 1992


signature.asc
Description: Digital signature (GPG/PGP)

Re: CDBS and dh_install

[Christoph Berg]

Re: Steve Langasek 2006-06-10 <[EMAIL PROTECTED]>
> Is it no longer a requirement of NM that applicants demonstrate themselves
> capable of putting together a source package without the use of rules
> helpers?

Not in that length. The template question used by most AMs is:

  Write a small shell script which does the following two things: 
 a. prints whether a Debian package archive file has a copyright file
in the appropriate location.
 b. prints out the package version from the control file which is
inside the .deb.
 You may use tar, ar, grep, etc., but not any middle or high-level
 dpkg tools.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Tollef Fog Heen]

Loïc Minier skrev:


 Is Debhelper our C and CDBS our C++?


CDBS is to debhelper as XSLT (or prolog) is to C (or another procedural 
language).


- tfheen

Re: CDBS and dh_install

[Jean Parpaillon]

Uhhh,
I did not want to launch such a big discussion :-)

Here is my opinion (this is my first packages for Debian, and people on
debian-mentors know it has not been easy to follow the whole policy ;-)

- I first used a simple "rules" script, because I can not imagine using
a wrapper while not knowing the system it is around.
- But now, I use CDBS because it is much simpler to follow the policies
with it, and to have "good practices", ie using *.install, *.dirs, etc.
files.
- I can use CDBS because the upstream sources are standards. Moreover,
I'm upstream devel too and I can easily fix issues in upstream rather
than writing hacks in the Debian sources.

To conclude, I will use CDBS because :
- I know how to write a package without it
- and there are no hacks in the packaging.


Jean


Le 10.06.2006 10:03, Loïc Minier a écrit :
> On Fri, Jun 09, 2006, martin f krafft wrote:
>   
>> This is my opinion and others will disagree:
>> Please don't. CDBS is a major pain to use for those who didn't
>> (co-)author it. It's just too much about obfuscation.
>> 
>
>  Yeah, I and others we disagree!  :)
>
>  CDBS makes maintenance of some packages damn easy: most changes are
>  done in debian/* files, where they belong.
>
>  Here's some piece of pure statistics, completely biased by the fact all
>  sources come from the same project:
>  - we have 84 GNOME "desktop" packages
>   
>  - 71 of these are CDBS
>  - they have an average debian/rules length of 18 lines (empty lines
>included, 13 lines if you exclude empty lines)
>
>  Of course, the shortest code is not necessarily the easiest to read,
>  but I don't consider these lines to be obfuscated either.  They might
>  be CDBS specific though, and require some CDBS understanding to parse.
>
>  My "feeling" is that CDBS works best with upstream tarballs following a
>  standard layout.  CDBS pushes us into storing meta-information about
>  the Debian packaging in separate files (debian/*.install,
>  debian/*.examples, debian/*.docs).  (Yes, this is an indirect
>  consequence of debhelper being well thought.)
>
>  The debian/rules ends up storing the _delta_ between what a normal
>  package would do and what is needed for this particular package.
>
>  But I understand CDBS can be slightly dangerous in subtle cases, and
>  difficult to grasp the first time you encounter CDBSized packages.
>  It's an useful evil.
>
>   


-- 
 
/ Il y a trois types de mathématiciens, \
| ceux qui savent compter et ceux qui ne |
\ savent pas./
 
\   ^__^
 \  (xx)\___
(__)\   )\/\
 U  ||w |
|| ||


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Thomas Weber]

Am Sonntag, den 11.06.2006, 11:30 +0100 schrieb Mark Brown:

> That's a bit different: updating the debhelper compat level is updated
> by the maintainer explicitly changing the package rather than by
> installing a new version of debhelper.

Well, I certainly agree that it is a bug if CDBS changes its behaviour
and the number is not bumped there as well. The problem currently seems
that CDBS is used for packages but actually still somewhat unstable. 

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Mark Brown]

On Sun, Jun 11, 2006 at 09:06:28AM +0200, Thomas Weber wrote:

> Well, how do I know if I have to deviate from the debhelper scripts at
> some point in the future? In fact, if I bump up the compat level, I
> might very well need to change my scripts.

That's a bit different: updating the debhelper compat level is updated
by the maintainer explicitly changing the package rather than by
installing a new version of debhelper.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Mike Hommey]

On Sun, Jun 11, 2006 at 03:00:12AM +0200, Marc Dequènes <[EMAIL PROTECTED]> 
wrote:
> In the past some mistakes were done in debhelper too, even if i don't
> recall a specific case to mention. 

Probably because a change in debhelper is done with a change of
compatibility level. And you still can use the old behaviour by using
the appropriate level.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Thomas Weber]

Am Samstag, den 10.06.2006, 15:38 -0700 schrieb Steve Langasek:
> Oh, I disagree; I think I have a pretty good idea what the benefits are of
> CDBS, I just think that many CDBS proponents underemphasize the *downside*
> of CDBS.
> 
> So tell me, how do you know a priori whether the software you're packaging
> is going to be "common", or if it's going to need to deviate from CDBS at
> some point in the future?  

Well, how do I know if I have to deviate from the debhelper scripts at
some point in the future? In fact, if I bump up the compat level, I
might very well need to change my scripts.

The difference is that joey is extremely careful not to break things
(and debhelper scripts are already quite mature).


> If you're recommending a packaging style to a new
> packager who probably doesn't have the level of committment to learn more
> than a single helper style, how do you know whether they will at some point
> need to package something that doesn't fit in cdbs's neat little view of the
> world?
I don't know it, but that's not the problem. CDBS is for the simple
cases where its neat little view is fulfilled. I believe a large number
of packages in Debian fit in this little view. Does it really make sense
to have long rules files for these packages? I believe packagers' time
is better spent on complicated packages, where CDBS isn't enough.

NM's using only CDBS will probably fail. 



> Er... is that really meant to be a defense of CDBS?  debhelper *does* have
> manpages, and this is an important part of why I think it's better.
It wasn't meant as a defense. Now, we have (basically) two choices: dump
CDBS or improve the docs.


> > I mean, if I want default values for a program, I do "./configure" and
> > not "./configure --enable-default-prefix --enable-default-docpath ..."
> 
> Hmm, interesting comparison, given all the arguments that cdbs itself passes
> to ./configure by default:
> 
>   --build=$(DEB_BUILD_GNU_TYPE) --prefix=$(DEB_CONFIGURE_PREFIX) \
>   --includedir=$(DEB_CONFIGURE_INCLUDEDIR) \
>   --mandir=$(DEB_CONFIGURE_MANDIR) --infodir=$(DEB_CONFIGURE_INFODIR) \
>   --sysconfdir=$(DEB_CONFIGURE_SYSCONFDIR) \
>   --localstatedir=$(DEB_CONFIGURE_LOCALSTATEDIR) \
>   --libexecdir=$(DEB_CONFIGURE_LIBEXECDIR) --disable-maintainer-mode \
>   --disable-dependency-tracking
> 
> :)
Yes, but I don't need to type this stuff myself (and it's there if I
need to override it) in dozens of packages.


> What problems does this cause?  I mean, I've heard of a few bugs from time
> to time caused by maintainers putting key debhelper commands out of order;
The right order surely was documented :)
But we all know (at least those with end user experience) that people
never read docs -- so why bother writing them? :)


Regards
Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Duck]

Coin,

Steve Langasek <[EMAIL PROTECTED]> writes:

> and replace it with a very small shell script.  For cdbs, you delete one
> line and have to replace it with your reimplementation of a very large
> makefile...

That's obvious because CDBS does not target at doing little independent
tasks (even if some may be *perhaps* be transformed to dh_*), but to
autogenerate rules. CDBS is a layer over debhelper, this cannot be
simply compared this way.

> Oh, I disagree; I think I have a pretty good idea what the benefits are of
> CDBS, I just think that many CDBS proponents underemphasize the *downside*
> of CDBS.

That's not true for everybody. The auto control generation is now never
run automatically because we agreed it could cause harm.

> So tell me, how do you know a priori whether the software you're packaging
> is going to be "common", or if it's going to need to deviate from CDBS at
> some point in the future?  If you're recommending a packaging style to a new
> packager who probably doesn't have the level of committment to learn more
> than a single helper style, how do you know whether they will at some point
> need to package something that doesn't fit in cdbs's neat little view of the
> world?

You simply don't care about this...
If something is missing or inadéquate you juste hook on makefile rules
and add your own commands (debhelper if necessary). you can even stop
including some classes and reimplement what is uncommon and thus has no
reason to be in a class. I never found any package being fully uncommon,
so i see no reason not to use CDBS if you feel well with this tool with
any package..

If the packager has no time to learn Debian tools correctly, then he
must not be sent to NM, or must not be accepted by AM or DAM, that's
really obvious. People willing to have a @debian.org email for fun or
unwilling to learn and work seriously can just can become MOTUs...
What would you say if i told you i had not yet time to learn how the
BTS work because my level of committment is not high enough and that i
won't be able to manage my bugs until 6 more months ?

Sometimes i really don't understand you...

> I was pointing out that you can't learn anything about what cdbs does by
> looking at the debian/rules of a package that uses it.  If I have a
> debian/rules file that invokes a command, and I don't understand what that
> command does, I can look at the manpage.  If I have a debian/rules file that
> includes other makefiles, my choices are to look at the include file itself
> and study it (for which the *shortest* of these is as long as the stock
> dh-make template rules file), or track down the cdbs documentation... which
> in at least one noteworthy case tells me to go look at the include files
> anyway (hee).

This was true and is less and less true. This case is in an unfinished
part (debhelper parameters), and i don't recall any other case. I'm not
sure in the youth of debhelper manpages were initially perfectly
exhaustive. This is very common in FOSS projects to have lacks of
documentation, CDBS is no exception.

The documentation is still work in progress and is actively improved
over time, just be patient *or* help.

> The flip side of this is that the behavior of cdbs-using packages is always
> changing, without the knowledge or control of the package maintainer.  E.g.,
> while I was drafting this message,
>  showed up
> in my mailbox...

In the past some mistakes were done in debhelper too, even if i don't
recall a specific case to mention. That's not often this happen to CDBS,
but i agree this should be avoided, that's why i'd like Peter to finaly
accept co-maintainership.

> No, clearly makefile includes shouldn't have manpages; but some kind of
> documentation that tells cdbs users what they should or shouldn't be able to
> depend on would be a good idea.  In the absence of such documentation I
> think the current answer to what they can depend on is actually "very
> little", which is a big part of why I don't encourage its use.

A documentation do exist, even if you seem to be completely blind and
features which are described are behaviors you can count on. When a
feature has changed for very important reasons like the control auto
generation one, a warning is displayed (so you know you cannot count on
it). Undocumented parts are either documentation lack or internal stuff
you should not care about and count on. Nevertheless, i do agree this
needs improvements (please reply to the part of the thread with bubule
if you want to continue on this specific topic).

-- 
Marc Dequènes (Duck)


pgpGN7Uu1aDZd.pgp
Description: PGP signature

Re: CDBS and dh_install

[Steve Langasek]

Bundling up a few replies here...

On Sat, Jun 10, 2006 at 10:02:26AM +0300, George Danchev wrote:

> I'm also debhelper fan ;-) but what makes you think that if you face a 
> problematic debhelper script you are not supposed to reimplement that 
> particular part of rules by hand as an interim workaround ?

I don't think I implied that it wouldn't be appropriate to do this --
actually, my point is precisely that there's a big gap in the *difficulty*
of doing this for debhelper vs. cdbs.  For debhelper, you delete one line
and replace it with a very small shell script.  For cdbs, you delete one
line and have to replace it with your reimplementation of a very large
makefile...

On Sat, Jun 10, 2006 at 10:39:32AM +0200, Thomas Weber wrote:
> first off, I'm neither a DD nor an NM, but I do some packaging work
> (thanks to alioth), As most people here argue against CDBS, I think the
> benefits of it are missed (if you didn't guess, I use it and I like it).

Oh, I disagree; I think I have a pretty good idea what the benefits are of
CDBS, I just think that many CDBS proponents underemphasize the *downside*
of CDBS.

> Am Freitag, den 09.06.2006, 15:10 -0700 schrieb Steve Langasek:
> > On Fri, Jun 09, 2006 at 02:02:48PM -0500, Manoj Srivastava wrote:
> > > > This is also my impression. CDBS might be nice to automate the task
> > > > "make a .deb out of this Gnome source", but imho it completely fails
> > > > when you want to deviate from the "standard" in any way.

> I guess this paragraph sums it up pretty good. CDBS is not the best
> choice if you need something  *not* _c_ommon. OTOH, if I see a CDBS
> based rules files with three lines, this tells me one thing pretty
> clearly: there's nothing unusual in this package.

So tell me, how do you know a priori whether the software you're packaging
is going to be "common", or if it's going to need to deviate from CDBS at
some point in the future?  If you're recommending a packaging style to a new
packager who probably doesn't have the level of committment to learn more
than a single helper style, how do you know whether they will at some point
need to package something that doesn't fit in cdbs's neat little view of the
world?

> > Let's compare debhelper to cdbs.
> I don't quite agree with your analysis. If you say "CDBS stuff is
> under /usr/share/cdbs", you must as well say "dh_* stuff is
> under /usr/share/perl5/Debian/Debhelper/". 

I was pointing out that you can't learn anything about what cdbs does by
looking at the debian/rules of a package that uses it.  If I have a
debian/rules file that invokes a command, and I don't understand what that
command does, I can look at the manpage.  If I have a debian/rules file that
includes other makefiles, my choices are to look at the include file itself
and study it (for which the *shortest* of these is as long as the stock
dh-make template rules file), or track down the cdbs documentation... which
in at least one noteworthy case tells me to go look at the include files
anyway (hee).

I dunno, maybe my work habits mean I'm missing out on some great IDE
features that make it non-painful to track through makefile includes, but
for me, about the second time I find myself typing /usr/share/ to look at a
file in order to understand what a package is doing, I start to get a little
grumpy about it. :)

> The problem is the documentation, which leaves room for improvement. I
> mean, how many people would understand dh_* without the manpages?

Er... is that really meant to be a defense of CDBS?  debhelper *does* have
manpages, and this is an important part of why I think it's better.

> I mean, if I want default values for a program, I do "./configure" and
> not "./configure --enable-default-prefix --enable-default-docpath ..."

Hmm, interesting comparison, given all the arguments that cdbs itself passes
to ./configure by default:

  --build=$(DEB_BUILD_GNU_TYPE) --prefix=$(DEB_CONFIGURE_PREFIX) \
  --includedir=$(DEB_CONFIGURE_INCLUDEDIR) \
  --mandir=$(DEB_CONFIGURE_MANDIR) --infodir=$(DEB_CONFIGURE_INFODIR) \
  --sysconfdir=$(DEB_CONFIGURE_SYSCONFDIR) \
  --localstatedir=$(DEB_CONFIGURE_LOCALSTATEDIR) \
  --libexecdir=$(DEB_CONFIGURE_LIBEXECDIR) --disable-maintainer-mode \
  --disable-dependency-tracking

:)

On Sat, Jun 10, 2006 at 11:08:15AM +0200, Loïc Minier wrote:
>  You are looking at the individual dh_* commands, but:
>  - the precise list of debhelper calls varies from package to package,
>there's nothing standard or documented in this
>  - the order of the debhelper calls varies from package to package

What problems does this cause?  I mean, I've heard of a few bugs from time
to time caused by maintainers putting key debhelper commands out of order;
but I've seen the same sort of thing happen to cdbs-using packages too, and
I don't see that having such slight variations in debian/rules files
seriously harming comprehension.

>  Compare with CDBS where the list of debhelper calls has some order
>  constraints and 

Re: CDBS and dh_install

[Duck]

Joey Hess <[EMAIL PROTECTED]> writes:

> To be fair, debhelper is not co-maintained either.

I never noticed it wasn't, but i do think it should. Fact is you're
taking far much care when integrating changes, that's a major
difference.

-- 
Marc Dequènes (Duck)


pgpmw2zfDouEZ.pgp
Description: PGP signature

Re: CDBS and dh_install

[Joey Hess]

Marc Dequènes wrote:
> in a better state now. But this raise another related subject: such an
> important package should be comaintained. Peter refused any cooperation,
> uploaded new versions while i proposed to review his changes with
> another developper

To be fair, debhelper is not co-maintained either.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Duck]

Christian Perrier <[EMAIL PROTECTED]> writes:

> Hmmm, that sounds weird to my ears as Peter is currently working with
> myself, Steve Langasek and Noèl Köthe on the samba packages...and this
> team work works pretty well.

Sounds very strange to me.

I reviewed his first upload, found a regression (not in the feature
because it was new, but in the global CDBS expected behavior), he
refused to admit it was important, and then did everything on his
own. He finaly accepted to give public access to the repository recently
after several people complained on the list. And moreover, he decided to
anihilate the documention changelog, which issue had to be moved to
-policy before he accepted to resurect it.

Some of these issues have public writings on the list.

> There has even been some situations where some of us (ok, mostly Steve
> who is very good at argumenting things when he disagrees) disagreed
> with Peter's choices and Peter happily reverted them.

He is acting as a lonesome cowboy with CDBS. And i think this now
important package (as it is now widely used), MUST be
comaintained. Other people in the team are not responsible since more
than a year, so he is really alone.

> So, I suspect some misunderstanding somewhere and I'm having hard
> times buying the fast that Peter Eisentraut is completely refusing
> team work. I'd suggest trying again, indeed.

No, i won't try anymore by myself, it is useless, he does not care. But
if your could ask him to express his problem with me or with
comaintainance clearly, i'd be happy to know where is the blocking
point. As you are getting on well with him, i'd be glad if you could
help.

Until this is solved, i'm still maintaining my original version, since
more people use it than the one in the package, but this is not an ideal
situation.

-- 
Marc Dequènes (Duck)


pgppLqfQbzMvs.pgp
Description: PGP signature

Re: CDBS and dh_install

[Christian Perrier]

> by NMU). The CDBS Team does no more exist and Peter is the only one
> working on it and refusing any help, that's a very bad situation.


Hmmm, that sounds weird to my ears as Peter is currently working with
myself, Steve Langasek and Noèl Köthe on the samba packages...and this
team work works pretty well.

There has even been some situations where some of us (ok, mostly Steve
who is very good at argumenting things when he disagrees) disagreed
with Peter's choices and Peter happily reverted them.

So, I suspect some misunderstanding somewhere and I'm having hard
times buying the fast that Peter Eisentraut is completely refusing
team work. I'd suggest trying again, indeed.




signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Duck]

Coin,

Christian Perrier <[EMAIL PROTECTED]> writes:

> I tend to agree.

I tend to agree too, every maintainer should be encouraged to understand
the packaging tools he is using. These tools are made to solve _common_
situations, so you have to understand what automatic mechanisms are
involved, and sometimes their behavior must be changed or a specific
rule written, so you need enought knowledge to write rules yourself
properly.

> I think it's important for new maintainers to understand how their
> packages are built. For this, the very classical approach of
> debian/rules with debhelper commands is a good compromise between
> readability and accessibility.

This is a good exercice, as packaging a medium difficulty package
without debhelper is a good NM excercice.

> On the other hand, the constant changes and new neat features
> introduced in Debian (new debhelper commands, new ways to handle
> stuff, etc) is a big challenge for maintainers to cope with (in short,
> I bet that mostly noone except the debhelper maintainer is really
> aware of all debhelper nice features).

Yep, and you can't ask a NM to deeply understand the insides of each
tools. But it must be aware of what it realy does. So i do agree to your
statement that the CDBS documentation has room for improvement.

> Using cdbs is indeed a very convenient way to be sure that packages
> use a kind of common build method, which allows major build design
> changes without big communication to developers. Of course, this
> assumes that cdbs is kept up-to-date with recent evolutions of the
> Debian packages build process and new neat features in debhelper.

It was not up-to-date for a long time, since Jeff Bailey moved to Ubuntu
has clearly has no remaining time for any Debian work. Peter Eisentraut
came hijacking the package and did a quite good job, so the package is
in a better state now. But this raise another related subject: such an
important package should be comaintained. Peter refused any cooperation,
uploaded new versions while i proposed to review his changes with
another developper, and finally any big mistake occured (#365085 fixed
by NMU). The CDBS Team does no more exist and Peter is the only one
working on it and refusing any help, that's a very bad situation.

For the documentation issue, CDBS only contained one or two files with
obsolete and not-understandable examples, which are now removed from the
package. When i came to CDBS i was moaning loudly about missing
documentation (GNOME Team people are witnesses), so i finaly decided to
write one. Jeff accepted me as being officially in charge of the
documentation, so i introduced it in July 2005. Peter decided to rework
it without any notice and then forked it because he refused to work with
me. He changed the tone of parts of the document, did some cosmetic
changes, but still his latest changes to the software remains
undocumented. I'm still maintaining the original documentation (which is
outside the alioth project because i never had any svn access, Jeff was
too busy). I also started translating in french (someone provided an
unfinished Brezilian translation a long while ago, but was later
unresponsive, so it is quite outdated now) using po4a.

So, i'm still willing to work on this documentation, but since Peter
does not want to deal with me, i'm stuck ; this has to be solved before
any major rewrite. Now that people are *really* interested in having a
better documentation, i would be happy to get help from bubule or anyone
with knowledge on CDBS and translations.

The original documentation can be found here:
  http://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml
(sources are in the 'cdbs-doc/' directory)

-- 
Marc Dequènes (Duck)


pgpXyuODfIshx.pgp
Description: PGP signature

Re: CDBS and dh_install

[martin f krafft]

also sprach Christian Perrier <[EMAIL PROTECTED]> [2006.06.10.1156 +0200]:
> Of course, it was not. I omitted to put smileys because it seems
> that some people around are thinking I'm sometimes too happy or
> saying too much fun things,

and that's negative? We never took you seriously anyway, must be
because of that yellow T-Shirt you wore in Oaxtepec. :_)

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"all i know is that i'm being sued for unfair business 
 practices by micro$oft. hello pot? it's kettle on line two."
  -- michael robertson


signature.asc
Description: Digital signature (GPG/PGP)

Re: CDBS and dh_install

[Eduard Bloch]

#include 
* Loïc Minier [Sat, Jun 10 2006, 11:08:15AM]:

>  Yes, I 100% agree with you.  Would I be evaluating an applicant, I
>  wouldn't like him to prepare a new source package in CDBS.  (But I
>  wouldn't request to build a .deb with ar either.)
> 
>  Is Debhelper our C and CDBS our C++?

No. Base system and dpkg-* tools are C, debhelper is C++ and CDBS is
J2EE+Spring but with 1% of their docs.

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Michael Banck]

On Sat, Jun 10, 2006 at 02:24:42AM +0200, Eduard Bloch wrote:
> Oh, really? The last time I tried to add a custom command to the install
> rule (well, >> 1 year ago) it was a real PITA. Docs have not told me how
> it works, docs have not told me in an understandable language how to add
> extensions, 

CDBS docs have improved somewhat significantly over the last year,
AFAIK (and are now included in the package as well, I believe).


Michael

-- 
* nyu is impressed at how jbailey can avoid even pings on questions he
already avoided
 nyu: This is what qualifies me to co-maintain glibc.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Christian Perrier]

Quoting martin f krafft ([EMAIL PROTECTED]):
> also sprach Christian Perrier <[EMAIL PROTECTED]> [2006.06.10.0852 +0200]:
> > But I suspect that implicitely telling Manoj that he thinks
> > top-down because he actually likes cdbs will get you into trouble,
> 
> It was not my intention.


Of course, it was not. I omitted to put smileys because it seems that
some people around are thinking I'm sometimes too happy or saying too
much fun things, but that was actually my intent, putting this
conversation in parallel with the one I had with Manoj on
debconf-discuss yesterdar, which turned into a kind of political
arguments exchange..:)




signature.asc
Description: Digital signature

Re: CDBS and dh_install

[martin f krafft]

also sprach Christian Perrier <[EMAIL PROTECTED]> [2006.06.10.0852 +0200]:
> But I suspect that implicitely telling Manoj that he thinks
> top-down because he actually likes cdbs will get you into trouble,

It was not my intention.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"i dislike arguments of any kind. they are always vulgar, and often
 convincing."
-- oscar wilde


signature.asc
Description: Digital signature (GPG/PGP)

Re: CDBS and dh_install

[Loïc Minier]

On Fri, Jun 09, 2006, Steve Langasek wrote:
> When using debhelper, you (typically) have a single debian/rules makefile
> which lists out all the commands that are invoked for building your package;
> each of those commands primarily uses the contents of other files in debian/
> as input.  If you have questions about what any one of those lines does,
> there is a manpage that you can refer to.  Thus, a debhelper-based
> debian/rules is composed of discrete units, each of which can be understood
> separately through the *documentation*, and the maintainer held to account
> if the behavior doesn't match the documentation, without any requirement
> that the user understand the implementation language of perl.

 You are looking at the individual dh_* commands, but:
 - the precise list of debhelper calls varies from package to package,
   there's nothing standard or documented in this
 - the order of the debhelper calls varies from package to package

 Compare with CDBS where the list of debhelper calls has some order
 constraints and where the list itself can evolve: introduction of
 dh_gconf in the rules used by GNOME packages is only a matter of adding
 the call to the relevant CDBS file, not to each individual package.

 I agree that it's a nice feature to be able to say dh_install conforms
 to its documentation, yet the same feature is available in CDBS which
 calls dh_install: the precise dh_install call will happen from CDBS
 instead of directly from your debian/rules, but you have the same
 documentation, and interface to write your debian/*.install files.

> In contrast, almost all of cdbs is stashed away in /usr/share/cdbs/; almost
> none of what it does is inspectible by looking at the debian/rules and using
> those lines as hooks into the documentation.  There is
> /usr/share/doc/cdbs/cdbs-doc.html, which documents many of the common
> variables one may wish to use, but there is no concise description of what
> the cdbs rules *themselves* do.  It's nice to know that you can supplement
> the standard rules with additional double-colon rules, but you're basically
> expected to trust that the default rules Do The Right Thing -- if you find
> that a cdbs rule does the wrong thing, your only recourses are to either try
> to fix up the output after the fact (assuming the Wrong Thing isn't a fatal
> failure), or to not include that problematic cdbs class and reimplement the
> rules by hand.

 Agreed, documentation is a bit lacking and could be improved.  More
 importantly, the interface is not as clearly defined as a command call,
 because Makefiles allow much more.  I can't imagine what to put in a
 simple-patchsys.mk man page, or it would be as long as the original
 makefile.

> Oh, and to top it off, almost all cdbs packages include
> /usr/share/cdbs/1/rules/debhelper.mk anyway, so they're still *using*
> debhelper behind the scenes. :)  Just not in a form that leaves the package
> maintainer any control over the process beyond that granted them by the
> cdbs maintainers...

 But these are great features: not only does it uses debhelper behind
 the scenes and let's you store meta-information in debian/* files (such
 as the examples in debian/package.examples), it will also spare you the
 time of writing and parsing a long list of dh_* calls that is present
 in pure "debhelper" packages.  Yes, you loose some control, but there
 are often ways to achieve what you need to.
   Besides, I don't think anyone will step up to claim that CDBS is good
 for all packages in Debian.  The very simple tasks that debhelper ships
 make it an omniscious build-dep, while the more high-level tasks of
 CDBS won't fit certain packages, for example they are particularly not
 suited to multiple builds of the same source.

> And btw, last I looked at the cdbs makefiles, they were among the most
> arcane uses of make syntax that I'd ever seen.

 Still, each time I grepped them for the override I was looking for, it
 worked.  :)

> Arguing that cdbs is good
> because make is a least common denominator language in Debian is like
> arguing that we should do GRs in iambic pentameter because English is the
> lingua franca.

 It factors code together, exactly as debhelper aims at, except it
 happens on a higher level with CDBS.

 After all, I could claim that everyone knows the interface to cp and
 mv, and use them instead of debhelper.

> There are also pretty significant differences in the design goals of
> debhelper and cdbs, differences which I believe have a major impact on the
> ability of maintainers to understand their own packages and on the
> respective helper-induced build failure rates of the two.  I think these are
> very pertinent reasons not to recommend cdbs to novice maintainers.

 Yes, I 100% agree with you.  Would I be evaluating an applicant, I
 wouldn't like him to prepare a new source package in CDBS.  (But I
 wouldn't request to build a .deb with ar

Re: CDBS and dh_install

[Thomas Weber]

Hi, 

first off, I'm neither a DD nor an NM, but I do some packaging work
(thanks to alioth), As most people here argue against CDBS, I think the
benefits of it are missed (if you didn't guess, I use it and I like it).

Am Freitag, den 09.06.2006, 15:10 -0700 schrieb Steve Langasek:
> On Fri, Jun 09, 2006 at 02:02:48PM -0500, Manoj Srivastava wrote:
> > > This is also my impression. CDBS might be nice to automate the task
> > > "make a .deb out of this Gnome source", but imho it completely fails
> > > when you want to deviate from the "standard" in any way.

I guess this paragraph sums it up pretty good. CDBS is not the best
choice if you need something  *not* _c_ommon. OTOH, if I see a CDBS
based rules files with three lines, this tells me one thing pretty
clearly: there's nothing unusual in this package.


> Let's compare debhelper to cdbs.
I don't quite agree with your analysis. If you say "CDBS stuff is
under /usr/share/cdbs", you must as well say "dh_* stuff is
under /usr/share/perl5/Debian/Debhelper/". 

The problem is the documentation, which leaves room for improvement. I
mean, how many people would understand dh_* without the manpages?



> /usr/share/cdbs/1/rules/debhelper.mk anyway, so they're still *using*
> debhelper behind the scenes. :)  
Yes, and that's a fact I like a lot. I mean, having debian/rules files
in different packages, which are almost exchangable, but still every
single one has > 50 lines, is unproductive. 
(Packaging-wise) simple packages should have simple and *short*
debian/rules files.

I mean, if I want default values for a program, I do "./configure" and
not "./configure --enable-default-prefix --enable-default-docpath ..."


Regards
Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Loïc Minier]

On Fri, Jun 09, 2006, martin f krafft wrote:
> This is my opinion and others will disagree:
> Please don't. CDBS is a major pain to use for those who didn't
> (co-)author it. It's just too much about obfuscation.

 Yeah, I and others we disagree!  :)

 CDBS makes maintenance of some packages damn easy: most changes are
 done in debian/* files, where they belong.

 Here's some piece of pure statistics, completely biased by the fact all
 sources come from the same project:
 - we have 84 GNOME "desktop" packages
 - 71 of these are CDBS
 - they have an average debian/rules length of 18 lines (empty lines
   included, 13 lines if you exclude empty lines)

 Of course, the shortest code is not necessarily the easiest to read,
 but I don't consider these lines to be obfuscated either.  They might
 be CDBS specific though, and require some CDBS understanding to parse.

 My "feeling" is that CDBS works best with upstream tarballs following a
 standard layout.  CDBS pushes us into storing meta-information about
 the Debian packaging in separate files (debian/*.install,
 debian/*.examples, debian/*.docs).  (Yes, this is an indirect
 consequence of debhelper being well thought.)

 The debian/rules ends up storing the _delta_ between what a normal
 package would do and what is needed for this particular package.

 But I understand CDBS can be slightly dangerous in subtle cases, and
 difficult to grasp the first time you encounter CDBSized packages.
 It's an useful evil.

-- 
Loïc Minier <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[George Danchev]

On Saturday 10 June 2006 01:10, Steve Langasek wrote:
--cut--
> In contrast, almost all of cdbs is stashed away in /usr/share/cdbs/; almost
> none of what it does is inspectible by looking at the debian/rules and
> using those lines as hooks into the documentation.  There is
> /usr/share/doc/cdbs/cdbs-doc.html, which documents many of the common
> variables one may wish to use, but there is no concise description of what
> the cdbs rules *themselves* do.  It's nice to know that you can supplement
> the standard rules with additional double-colon rules, but you're basically
> expected to trust that the default rules Do The Right Thing -- if you find
> that a cdbs rule does the wrong thing, your only recourses are to either
> try to fix up the output after the fact (assuming the Wrong Thing isn't a
> fatal failure), or to not include that problematic cdbs class and
> reimplement the rules by hand.

I'm also debhelper fan ;-) but what makes you think that if you face a 
problematic debhelper script you are not supposed to reimplement that 
particular part of rules by hand as an interim workaround ?

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Christian Perrier]

> Because there is documentation telling what is going behind the scenes?
> Like understandable manpages for every debhelper command.


Sure. I think that we basically here all agree that, whether we
actually like cdbs or not, its documentation has a lot of room for
improvement...




signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Christian Perrier]

Quoting Russ Allbery ([EMAIL PROTECTED]):
> Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > Is it no longer a requirement of NM that applicants demonstrate
> > themselves capable of putting together a source package without the use
> > of rules helpers?
> 
> Well, I've never actually done this, and I got through NM.  (I've always
> used debhelper, although I've sponsored and/or comaintained packages using
> CDBS before and have poked a little at yada.)  I'm certain that I *could*
> do this if I wanted to, as it's all fairly clearly documented, but I've
> never gone through the exercise.


I'm certain that I *couldn't* do this and I also went through NM
(actually I really wonder whether I could go through NM *now* indeed).




signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Christian Perrier]

>   cdbs is top-down because it defines the package build as much as
>   possible in line with how the cdbs developers think it should be
>   done. It expects the developer to tweak the countless,
>   undocumented parameters until it's right.
> 
>   debhelper is bottom-up because it gives you small tools that each
>   do their own thing. You then get to put them together to
>   accomplish what you want to accomplish.


Yeah. Interesting analogy.

So, actually, we have tools for both ways of thinking. Which is Good,
isn't it? After all, Unix is also the philosophy of achieving the
goals you have with the tools you find appropriate with regards of
your way to think

But I suspect that implicitely telling Manoj that he thinks top-down
because he actually likes cdbs will get you into trouble,
dude. Top-down is not exactly a very liberal attitude (reference to a
thread in debconf-discuss for those not aware).(just small pun
intended)





signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Christian Perrier]

> There are also pretty significant differences in the design goals of
> debhelper and cdbs, differences which I believe have a major impact on the
> ability of maintainers to understand their own packages and on the
> respective helper-induced build failure rates of the two.  I think these are
> very pertinent reasons not to recommend cdbs to novice maintainers.


I tend to agree.

I think it's important for new maintainers to understand how their
packages are built. For this, the very classical approach of
debian/rules with debhelper commands is a good compromise between
readability and accessibility.

On the other hand, the constant changes and new neat features
introduced in Debian (new debhelper commands, new ways to handle
stuff, etc) is a big challenge for maintainers to cope with (in short,
I bet that mostly noone except the debhelper maintainer is really
aware of all debhelper nice features).

Using cdbs is indeed a very convenient way to be sure that packages
use a kind of common build method, which allows major build design
changes without big communication to developers. Of course, this
assumes that cdbs is kept up-to-date with recent evolutions of the
Debian packages build process and new neat features in debhelper.

I actually use cdbs for several of my packages, the most important
being shadow (others are font packages which are usually very
simple). In that specific case, I find it particularly convenient
because it allows the debian/rules to only list actions that are very
specific (actually, things that are done "by hand" for various
reasons, good or bad).

The funny goal of having one-liner debian/rules files, with cdbs, is
indeed a very good way to track down all hacks, dirty or not, we are
currently using in debian/rules fileswhich is, for the long term,
a good improvement.

But, be safe, Steve, I won't push for cdbs in samba (even though,
ahem, it's debian/rules file has room for improvement probably)..



signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Eduard Bloch]

#include 
* Manoj Srivastava [Fri, Jun 09 2006, 02:02:48PM]:
> On 9 Jun 2006, Christoph Berg said:

> > This is also my impression. CDBS might be nice to automate the task
> > "make a .deb out of this Gnome source", but imho it completely fails
> > when you want to deviate from the "standard" in any way.
> 
> I am surprised to hear you say so, since CDBS is one of the
>  most configurable build systems out there. You can add commands to
>  any phase of the build, by just adding targets/dependencies/variables. 

Oh, really? The last time I tried to add a custom command to the install
rule (well, >> 1 year ago) it was a real PITA. Docs have not told me how
it works, docs have not told me in an understandable language how to add
extensions, and after trying to find a proper way to insert a command by
myself, I gave up and threw it away.

So I have to agree with Martin here.

> > CDBS hides what it's going on while building the package. It is very 
> > hard to see what it does, and if you are a newcomer, it is next to
> > impossible to actually learn anything from using it. (And the syntax
> > is very ugly.)
> 
> Very subjective. I mean, heavens, cdbs is just a make file,
>  and we all have some need to know how make works, as opposed to
>  learning python/Perl/ruby or whatever other languages a helper
>  package may be written in.

Choice of language is not an excuse. You can write a lot of ugly things
with Makefiles.

> > Again, I'm fine if you use CDBS for your package, but please never
> > recommend it to any new maintainer.
> 
> Why would this not apply to any other helper packages as well?

Because there is documentation telling what is going behind the scenes?
Like understandable manpages for every debhelper command.

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Russ Allbery]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Is it no longer a requirement of NM that applicants demonstrate
> themselves capable of putting together a source package without the use
> of rules helpers?

Well, I've never actually done this, and I got through NM.  (I've always
used debhelper, although I've sponsored and/or comaintained packages using
CDBS before and have poked a little at yada.)  I'm certain that I *could*
do this if I wanted to, as it's all fairly clearly documented, but I've
never gone through the exercise.

I agree with all the complaints Steve has, but the one that bugs me the
most is the lack of documentation.  If something goes wrong with CDBS,
there really doesn't seem to be a recourse other than figuring out what's
going on by reading the source.  We had a problem with Shishi with
dependencies not showing up in the dependency list of the built packages
that was worked around by reordering the packages in debian/control, and I
never could figure out just what was going on from the CDBS makefiles.  (I
believe this bug has subsequently been fixed.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[martin f krafft]

also sprach Steve Langasek <[EMAIL PROTECTED]> [2006.06.10.0010 +0200]:
> Let's compare debhelper to cdbs.

... this makes me think:

  cdbs is top-down because it defines the package build as much as
  possible in line with how the cdbs developers think it should be
  done. It expects the developer to tweak the countless,
  undocumented parameters until it's right.

  debhelper is bottom-up because it gives you small tools that each
  do their own thing. You then get to put them together to
  accomplish what you want to accomplish.

Those who know me also know that I am a big fan of anything
bottom(s)-up.

And guess which approach is more reminiscent of the Unix philosophy?

> Is it no longer a requirement of NM that applicants demonstrate
> themselves capable of putting together a source package without
> the use of rules helpers?

was it ever?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"in the country of the blind,
 the one-eyed man is not king.
 he is taken to be a hallucinating lunatic."
 -marshall mcluhan


signature.asc
Description: Digital signature (GPG/PGP)

Re: CDBS and dh_install

[Steve Langasek]

On Fri, Jun 09, 2006 at 02:02:48PM -0500, Manoj Srivastava wrote:

> >> This is my opinion and others will disagree:
> >> Please don't. CDBS is a major pain to use for those who didn't
> >> (co-)author it. It's just too much about obfuscation.

> > This is also my impression. CDBS might be nice to automate the task
> > "make a .deb out of this Gnome source", but imho it completely fails
> > when you want to deviate from the "standard" in any way.

> I am surprised to hear you say so, since CDBS is one of the
>  most configurable build systems out there. You can add commands to
>  any phase of the build, by just adding targets/dependencies/variables. 

> Off hand, I would say that the cdbs approach is as flexible as
>  any one might find.

Flexible, yes.  Accessible?

> > CDBS hides what it's going on while building the package. It is very 
> > hard to see what it does, and if you are a newcomer, it is next to
> > impossible to actually learn anything from using it. (And the syntax
> > is very ugly.)

> Very subjective. I mean, heavens, cdbs is just a make file,
>  and we all have some need to know how make works, as opposed to
>  learning python/Perl/ruby or whatever other languages a helper
>  package may be written in.

> I haven't really found the CDBS makefiles very hard to follow,
>  but that again is subjective.

Let's compare debhelper to cdbs.

When using debhelper, you (typically) have a single debian/rules makefile
which lists out all the commands that are invoked for building your package;
each of those commands primarily uses the contents of other files in debian/
as input.  If you have questions about what any one of those lines does,
there is a manpage that you can refer to.  Thus, a debhelper-based
debian/rules is composed of discrete units, each of which can be understood
separately through the *documentation*, and the maintainer held to account
if the behavior doesn't match the documentation, without any requirement
that the user understand the implementation language of perl.

In contrast, almost all of cdbs is stashed away in /usr/share/cdbs/; almost
none of what it does is inspectible by looking at the debian/rules and using
those lines as hooks into the documentation.  There is
/usr/share/doc/cdbs/cdbs-doc.html, which documents many of the common
variables one may wish to use, but there is no concise description of what
the cdbs rules *themselves* do.  It's nice to know that you can supplement
the standard rules with additional double-colon rules, but you're basically
expected to trust that the default rules Do The Right Thing -- if you find
that a cdbs rule does the wrong thing, your only recourses are to either try
to fix up the output after the fact (assuming the Wrong Thing isn't a fatal
failure), or to not include that problematic cdbs class and reimplement the
rules by hand.  Oh, and to top it off, almost all cdbs packages include
/usr/share/cdbs/1/rules/debhelper.mk anyway, so they're still *using*
debhelper behind the scenes. :)  Just not in a form that leaves the package
maintainer any control over the process beyond that granted them by the
cdbs maintainers...

And btw, last I looked at the cdbs makefiles, they were among the most
arcane uses of make syntax that I'd ever seen.  Arguing that cdbs is good
because make is a least common denominator language in Debian is like
arguing that we should do GRs in iambic pentameter because English is the
lingua franca. :)

> > Again, I'm fine if you use CDBS for your package, but please never
> > recommend it to any new maintainer.

> Why would this not apply to any other helper packages as well?

Is it no longer a requirement of NM that applicants demonstrate themselves
capable of putting together a source package without the use of rules
helpers?

There are also pretty significant differences in the design goals of
debhelper and cdbs, differences which I believe have a major impact on the
ability of maintainers to understand their own packages and on the
respective helper-induced build failure rates of the two.  I think these are
very pertinent reasons not to recommend cdbs to novice maintainers.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: CDBS and dh_install

[Daniel Jacobowitz]

On Fri, Jun 09, 2006 at 02:02:48PM -0500, Manoj Srivastava wrote:
> I am surprised to hear you say so, since CDBS is one of the
>  most configurable build systems out there. You can add commands to
>  any phase of the build, by just adding targets/dependencies/variables. 

If you can figure out where they go.  The last time I had to adjust my
(CDBS-using) build process I wasted an hour grepping around in
/usr/share/cdbs.

I think what CDBS could really use would be an improved manual.  The
examples don't cover a lot of things you can do with it.

-- 
Daniel Jacobowitz
CodeSourcery


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Manoj Srivastava]

On 9 Jun 2006, Christoph Berg said:

> Re: martin f krafft 2006-06-09
> <[EMAIL PROTECTED]>
>> also sprach Jean Parpaillon <[EMAIL PROTECTED]> [2006.06.09.1118
>> +0200]:
>>> I want to migrate my package (wormux) to CDBS.
>>
>> Why?
>
> I was just about to ask the same. Which packaging scheme do you use
> now?
>
>> This is my opinion and others will disagree:
>> Please don't. CDBS is a major pain to use for those who didn't
>> (co-)author it. It's just too much about obfuscation.
>
> This is also my impression. CDBS might be nice to automate the task
> "make a .deb out of this Gnome source", but imho it completely fails
> when you want to deviate from the "standard" in any way.

I am surprised to hear you say so, since CDBS is one of the
 most configurable build systems out there. You can add commands to
 any phase of the build, by just adding targets/dependencies/variables. 

Off hand, I would say that the cdbs approach is as flexible as
 any one might find.

> CDBS hides what it's going on while building the package. It is very 
> hard to see what it does, and if you are a newcomer, it is next to
> impossible to actually learn anything from using it. (And the syntax
> is very ugly.)

Very subjective. I mean, heavens, cdbs is just a make file,
 and we all have some need to know how make works, as opposed to
 learning python/Perl/ruby or whatever other languages a helper
 package may be written in.


I haven't really found the CDBS makefiles very hard to follow,
 but that again is subjective.

> Sorry for the rant, please read this as a "kids, please don't try
> this at home" message. I've seen way too many requests on -mentors
> or -mentors where people tried to use CDBS and failed just because
> it is evil black magic. (In one case a guy even said something like
> "I have bug foo in my package, I've even tried to repackage it using
> CDBS but it didn't help" - madness lies along this path.)

I have expressed similar reservations about helper packages in
 general (including debhelper).

> Again, I'm fine if you use CDBS for your package, but please never
> recommend it to any new maintainer.

Why would this not apply to any other helper packages as well?

manoj
-- 
"Infidels in all ages have battled for the rights of man, and have at
all times been the fearless advocates of liberty and justice."--
Robert Green Ingersoll
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Adeodato Simó]

* Christoph Berg [Fri, 09 Jun 2006 19:30:27 +0200]:

> Again, I'm fine if you use CDBS for your package, but please never
> recommend it to any new maintainer.

Full ack, seconded.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Alejandro Sanz - Que no te daría yo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Christoph Berg]

Re: martin f krafft 2006-06-09 <[EMAIL PROTECTED]>
> also sprach Jean Parpaillon <[EMAIL PROTECTED]> [2006.06.09.1118 +0200]:
> > I want to migrate my package (wormux) to CDBS.
> 
> Why?

I was just about to ask the same. Which packaging scheme do you use
now?

> This is my opinion and others will disagree:
> Please don't. CDBS is a major pain to use for those who didn't
> (co-)author it. It's just too much about obfuscation.

This is also my impression. CDBS might be nice to automate the task
"make a .deb out of this Gnome source", but imho it completely fails
when you want to deviate from the "standard" in any way.

CDBS hides what it's going on while building the package. It is very
hard to see what it does, and if you are a newcomer, it is next to
impossible to actually learn anything from using it. (And the syntax
is very ugly.)

Sorry for the rant, please read this as a "kids, please don't try this
at home" message. I've seen way too many requests on -mentors or
#-mentors where people tried to use CDBS and failed just because it is
evil black magic. (In one case a guy even said something like "I have
bug foo in my package, I've even tried to repackage it using CDBS but
it didn't help" - madness lies along this path.)

Again, I'm fine if you use CDBS for your package, but please never
recommend it to any new maintainer.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: CDBS and dh_install

[martin f krafft]

also sprach Adeodato Simó <[EMAIL PROTECTED]> [2006.06.09.1747 +0200]:
> > This is old. Why not switch to debhelper compatibility level 5,
> > which includes switching to a new format for *.install files?
> 
> What new format?

Sorry, there's no old and new. There's one and two column, the first
of which needs --sourcedir. They are both equally acceptable.

Cheers,

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
quantum mechanics: the dreams stuff is made of.


signature.asc
Description: Digital signature (GPG/PGP)

Re: CDBS and dh_install

[martin f krafft]

also sprach Andreas Metzler <[EMAIL PROTECTED]> [2006.06.09.1724 +0200]:
> For my own packages I usually do not use debhelper features
> unavailable in stable as I like to be able to make backports
> easily.

Then use compatibility level 4. Debhelper 5 *is* on backports.org
though.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"the perfect gun is an idealist without any ideal."
  -- mc 900 ft jesus


signature.asc
Description: Digital signature (GPG/PGP)

Re: CDBS and dh_install

[Adeodato Simó]

* martin f krafft [Fri, 09 Jun 2006 15:19:03 +0200]:

> This is old. Why not switch to debhelper compatibility level 5,
> which includes switching to a new format for *.install files?

What new format?

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Listening to: Presuntos Implicados - Samurai


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Andreas Metzler]

martin f krafft  debian.org> writes:
[...] 
> also sprach Andreas Metzler  downhill.at.eu.org>
[2006.06.09.1337 +0200]:
>> I am using
>> DEB_DH_INSTALL_SOURCEDIR = debian/tmp
>> for that purpose.
 
> This is old. Why not switch to debhelper compatibility level 5,
> which includes switching to a new format for *.install files?
[...]

For my own packages I usually do not use debhelper features unavailable in
stable as I like to be able to make backports easily.
cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Adeodato Simó]

* Jean Parpaillon [Fri, 09 Jun 2006 11:18:07 +0200]:

> Why do the default behaviour of dh_install is not to get files in
> 'debian/tmp' ?

That was the default behavior for the old dh_movefiles, which got
deprecated in debhelper 4 in favour of dh_install (see the changelog for
4.0.0 for details).

AIUI, one of the design decisions in dh_install was that its file lists
would be relative to the top level dir, which makes sense if you take
into account that all debhelper commands run from the top level dir.

The --sourcedir option was introduced in 4.0.4 to ease the migration
from the list of files for dh_movefiles to that of dh_install.

> And am I right with my solutions ?

Yes.


* Jean Parpaillon [Fri, 09 Jun 2006 13:44:59 +0200]:

> But the real question is : why it is not the default behaviour ? Is it a
> bug in CDBS or a feature ;-)

See above. CDBS defaults to debhelper's defaults, which is sane. If you care
about numbers, you'll see that CDBS's default would just fit the majority of
packages that use dh_install.

  @gluck:/org/lintian.debian.org/laboratory/source
  % grep -e --sourcedir=debian/tmp -l **/rules | wc -l
  509

  @gluck:/org/lintian.debian.org/laboratory/source
  % grep dh_install -l **/rules | xargs grep -e --sourcedir=debian/tmp -L | wc 
-l
  8374

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
 Listening to: Rosa León - El día que me quieras

Re: CDBS and dh_install

[martin f krafft]

also sprach Jean Parpaillon <[EMAIL PROTECTED]> [2006.06.09.1118 +0200]:
> I want to migrate my package (wormux) to CDBS.

Why?

This is my opinion and others will disagree:
Please don't. CDBS is a major pain to use for those who didn't
(co-)author it. It's just too much about obfuscation.

> In the .install files, path are not prefixed by
> "debian/tmp" so the building fail.

They should not be.

also sprach Andreas Metzler <[EMAIL PROTECTED]> [2006.06.09.1337 +0200]:
> I am using
> DEB_DH_INSTALL_SOURCEDIR = debian/tmp
> for that purpose.

This is old. Why not switch to debhelper compatibility level 5,
which includes switching to a new format for *.install files?

also sprach Jean Parpaillon <[EMAIL PROTECTED]> [2006.06.09.1344 +0200]:
> But the real question is : why it is not the default behaviour
> ? Is it a bug in CDBS or a feature ;-)

man dh_install
man debhelper

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"never attribute to malice what can be
 adequately explained by incompetence." 
   -- mark twain


signature.asc
Description: Digital signature (GPG/PGP)

Re: CDBS and dh_install

[Jean Parpaillon]

Le 09.06.2006 13:37, Andreas Metzler a écrit :
> Jean Parpaillon  altern.org> writes:
>   
>> I want to migrate my package (wormux) to CDBS.
>> In the .install files, path are not prefixed by "debian/tmp" so
>> the building fail.
>> It seems that I can correct this in 2 ways:
>> - either I prefix the paths with debian/tmp
>> - or I can set a special variable (DEB_DESTDIR, am I right ?) to debian/tmp
>> 
> [...]
>
> Hej,
> I am using
> DEB_DH_INSTALL_SOURCEDIR = debian/tmp
> for that purpose.
> cu andreas
>
>
>   
Thanks, it works fine.
But the real question is : why it is not the default behaviour ? Is it a
bug in CDBS or a feature ;-)

Jean

-- 
 
/ J'ai emprunté ma chaumière Aux puces \
| et aux moustiques Et j'ai dormi -+-|
\ Issa -+-   /
 
\   ^__^
 \  (..)\___
(__)\   )\/\
||w |
|| ||


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Andreas Metzler]

Jean Parpaillon  altern.org> writes:
> I want to migrate my package (wormux) to CDBS.
> In the .install files, path are not prefixed by "debian/tmp" so
> the building fail.
> It seems that I can correct this in 2 ways:
> - either I prefix the paths with debian/tmp
> - or I can set a special variable (DEB_DESTDIR, am I right ?) to debian/tmp
[...]

Hej,
I am using
DEB_DH_INSTALL_SOURCEDIR = debian/tmp
for that purpose.
cu andreas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: CDBS and dh_install

[Stephen Gran]

This one time, at band camp, Jean Parpaillon said:
> Hi,
> I want to migrate my package (wormux) to CDBS.
> In the .install files, path are not prefixed by "debian/tmp" so
> the building fail.
> It seems that I can correct this in 2 ways:
> - either I prefix the paths with debian/tmp
> - or I can set a special variable (DEB_DESTDIR, am I right ?) to debian/tmp
> 
> Why do the default behaviour of dh_install is not to get files in
> 'debian/tmp' ? And am I right with my solutions ?

I think cdbs looks at your debian/compat level for where to install the
files.  For recent compat levels, it wants to install to
debian/$package.  I am not sure of the solution, but it may just be
simplest to migrate to the new directory location.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature