Re: dpkg semi-hijack - an announcement (also, triggers)

[Ian Jackson]

Andreas Tille writes ("Re: dpkg semi-hijack - an announcement (also, 
triggers)"):
> Well, I don't want to interrupt your guys thrilling discussion
> about indentation of source code and I can not really imagine
> that you are not aware of
> apt-cache show indent

Running indent on an existing body of code is a bad idea.

> but isn't it a usual behaviour that a group decides about a
> certain policy of formatting code and then sticks to it?

This is done at the beginnings of projects precisely to avoid this
kind of nonsense.  If I had written a `coding style' document in the
root of the dpkg tree then Guillem would probably have now felt
entitled to just change it.

> Just a shy try to calm down from a poor outsider who really
> wonders how people could flame about whitespaces...

What I'm flaming about is that WE STILL DON'T HAVE TRIGGERS !

The _excuse_ that has been given is that the git log was not pretty
enough and they didn't like the formattting.

Ian.


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

Re: dpkg semi-hijack - an announcement (also, triggers)

[Ian Jackson]

John Goerzen writes ("Re: dpkg semi-hijack - an announcement (also, triggers)"):
> I think both you and Ian are making a mountain out of a molehill here.  So 
> what if the history isn't pretty?  It won't impact anybody running dpkg.  It 
> likely won't even impact the people hacking on dpkg.  In fact, 2 years 
> hence, I bet nobody cares.  Just git merge and be done with it.

That's what I did, in Augustt and in October.   The third time I did
it I uploaded the result.  It got unaccepted because the dpkg team are
more interested in blocking.

I'm not sure how I'm making a mountain out of a molehill.

I'm complaining that Guillem and Raphael have refused for 6 months to
take my code because of complaints which are both trivial and wrong.

Ian.


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

Suggested improvements for handling Architecture independent packages

[Julian Andres Klode]

Dear readers:

I would like to suggest two major improvements related to packages which are
"Architecture: all".

The first thing I want to suggest is the handling of dependencies. When building
a package, you can use "Depends: package [arch1 arch2]" which means that it
depends on package only on the architectures arch1 and arch2. But this only
works for architecture dependent packages. Therefore, I would like to not
process this "command" during the build-time, but do it at the installation 
time.

This is especially useful for recommends, since all recommends have to be
available. Without it, the best way is to only suggest the package.

One could also use package | not+ARCHITECTURE, but this results in half-broken
dependencies. And it's more complicated.

I suggested this first in Bug#436733 [1]

The other suggestion [2] is to add a field called "Install-Architecture" to the
control file, listing architectures for which this package should be available.
Another idea is to use "Architecture: all [i386 amd64 ppc]", which seems to be
better [3].

It would be great to add the needed functionality before the release of Lenny,
so we can start using it in Lenny+1.

The second suggested improvement could be used before the release of lenny,
because it would only require changes to dak (and maybe dpkg-dev, lintian). dak
would parse the value of "Architectures" to check for the architectures listed
in "[i386 amd64 ppc]".

When the package is added to the Packages file, the field gets changed to
"Architecture: all". This would be the easiest way.

Regards,

Julian

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436733
[2] http://lists.debian.org/debian-devel/2008/02/msg00045.html
[3] http://lists.debian.org/debian-devel/2008/02/msg00355.html
-- 
Julian Andres Klode, Fellow of the Free Software Foundation Europe
 Debian Maintainer | Developer | Ubuntu Member

try Debian: http://www.debian.org/ | my site: http://jak-linux.org/
jabber: [EMAIL PROTECTED] | IRC: juliank (FreeNode, OFTC)
languages: German  | English



signature.asc
Description: OpenPGP digital signature

Re: Suggested improvements for handling Architecture independent packages

[Bas Wijnen]

Hi,

On Thu, Mar 13, 2008 at 03:20:28PM +0100, Julian Andres Klode wrote:
> I would like to suggest two major improvements related to packages
> which are "Architecture: all".
> 
> The first thing I want to suggest is the handling of dependencies.
> When building a package, you can use "Depends: package [arch1 arch2]"
> which means that it depends on package only on the architectures arch1
> and arch2. But this only works for architecture dependent packages.
> Therefore, I would like to not process this "command" during the
> build-time, but do it at the installation time.
> 
> This is especially useful for recommends, since all recommends have to
> be available. Without it, the best way is to only suggest the package.

I don't see the "major improvement".  Why would you want to use this?  I
see two reasons:

- There is a real Recommends: relation, but the target package is not
  available on some architectures.  In this case, excluding them from
  the recommends list would hide the bug instead of fixing it.

- In rare cases, I can imagine that some really low-level tool is not
  available, especially on different kernels (kfreebsd or hurd, for
  example).  While this is a legitimate reason, I think it's so rare
  that it certainly doesn't count as "major improvement".

> The other suggestion [2] is to add a field called
> "Install-Architecture" to the control file, listing architectures for
> which this package should be available.  Another idea is to use
> "Architecture: all [i386 amd64 ppc]", which seems to be better [3].

This sounds useful, indeed.  If you have the coding skills, I think
patches would be appreciated. ;-)

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Tollef Fog Heen]

* Mike Bird 

| Please recall that Ian wrote dpkg (replacing Murdock's earlier
| PERL dpkg).  Ian knows dpkg better than any of the current team.

Ian had one upload of dpkg after September 1996, which was in 1998
before he suddenly regained interest in it about a year or so ago. I'm
not questioning his motives, I am just pointing out that iwj
maintained it for about two out of its fourteen-year life.  Calling
the project Ian's and implying that he has a god-given right to take
back dpkg because he first wrote it is just silly.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


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

Typos in dpkg man pages

[Helge Kreutzmann]

Hello,
while updating the German translation I noticed the following errors
in the man pages. Please do not update the German translation
afterwards.

#:../../man/dpkg-buildpackage.1:145
-(for example by using B as I)
+(for example by calling B to build the 
package)

#: ../../man/dpkg-buildpackage.1:226
-"Optimization options which are passed to the debian build system and can/"
+"Optimization options which are passed to the Debian build system and can/"
-"O2> , or B<-g\\ -O0> if B is specified in DEB_BUILD_OPTIONS). "
+"O2>, or B<-g\\ -O0> if B is specified in DEB_BUILD_OPTIONS). "

#: ../../man/dpkg-buildpackage.1:259
-"Preprocessor flags which are passed to the debian build system and can/"
+"Preprocessor flags which are passed to the Debian build system and can/"
-"B"
+"B.)"

#: ../../man/dpkg-buildpackage.1:246
-msgid "Same as B for Fortran sources."
+msgid "Same as B for Fortran sources."

#: ../../man/dpkg-checkbuilddeps.1:33
-"debian/control file."
+"I file."

#: ../../man/dpkg-genchanges.1:85
Here I noticed that for some man pages you use B<> to denote file
names, while for others you use I<>. This possibly should be unified.

#: ../../man/start-stop-daemon.8:192
-"specify a group by appending a B<:>, then the group or gid in the same way "
+"specify a group by appending a B<:>, then describe the group or gid in the 
same way "

-- 
  Dr. Helge Kreutzmann [EMAIL PROTECTED]
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Re: dpkg semi-hijack - an announcement (also, triggers)

[Guillem Jover]

On Wed, 2008-03-12 at 10:01:35 +, Ian Jackson wrote:
> Guillem Jover writes ("Re: dpkg semi-hijack - an announcement (also, 
> triggers)"):
> > On Mon, 2008-03-10 at 14:42:48 +1000, Anthony Towns wrote:
> > > Against the wishes of, afaict, Guillem and Raphael, Ian's made applying
> > > his triggers patch dependent on:
> > > 
> > >   - reversion to two space indenting

I seems I'll need to clarify this as well, as it's not correct, and has
been brought somewhere else... The rest has already been explained
several times, and I don't think there's any need to be repetitive.

> The history of this change is as follows:
>   * At some point, without any kind of discussion, Guillem
> unilaterally reformats several files to 8-character indents.

This is not correct. The changes referred to in bug 375711 were
introduced when:

  Wichert reindents configure.c:

  

  Initial version by Wichert of showpkg.c:

  

  New function by Fumitoshi Ukai in archives.c:

  

  Initial version of tarfn.c (git history does not go further and the
  ChangeLog is not detailed enough, from the header I assume it was
  Bruce Perens):

  

>   * On the *26th of June 2006* I noticed this because it caused
> an unnecessary merge conflict while I was trying to do a merge
> between the Ubuntu and Debian versions of dpkg.

I doubt actually this caused any merge conflict, given that those files
had been this way for a long long time.

>   * I thought it was a mistake because surely no-one would
> deliberately change the indent depth in an existing piece of free
> software.  (A plausible mechanism for the mistake involves an
> editor with tab-width set to 2; these kind of things do happen
> occasionally.)

It does not matter if it was a mistake or not, this kind of change
should have never landed in any unrelated non-official branch mixed
with other stuff. And I disagree that no one would want to change
coding style as I explained in:

  

>   * I therefore posted saying to debian-dpkg that this loooked like a
> mistake.  I also filed a bug, #375711, with a patch to revert the
> change.
>   * On the *30th of May 2007* I got the same merge conflict again in a
> later merge.  My bug report had gone unanswered.  By this point
> there is a considerable body of changes in Ubuntu which ought to
> be merged into Debian, all of which have the original formatting
> as I requested in my bug report.

The patch in that bug had been partially applied (explained at [0]):

  

And I guess at this point I should have just closed the bug, but this
was a continuos source of conflict, so leaving it open seemed to be
the less annoying.

I disagree with the rest of the patch[1], which was also wrong (due to
the resulting mixed indentantion), as I explained at:

  [0] 

  [1] 


>   * So I post to debian-dpkg again and Guillem tells me it was
> deliberate.

I said in [0] that "I think that those changes were done on purpose".

guillem


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

Re: Typos in dpkg man pages

[Guillem Jover]

Hi Helge,

On Thu, 2008-03-13 at 22:34:28 +0100, Helge Kreutzmann wrote:
> while updating the German translation I noticed the following errors
> in the man pages. Please do not update the German translation
> afterwards.
> 
> #:../../man/dpkg-buildpackage.1:145
> -(for example by using B as 
> I)
> +(for example by calling B to build the 
> package)

I don't think this change is correct, as here it's referring to it as
an argument to a command line option.

> #: ../../man/dpkg-buildpackage.1:226
> -"Optimization options which are passed to the debian build system and can/"
> +"Optimization options which are passed to the Debian build system and can/"

> -"O2> , or B<-g\\ -O0> if B is specified in DEB_BUILD_OPTIONS). "
> +"O2>, or B<-g\\ -O0> if B is specified in DEB_BUILD_OPTIONS). "

> #: ../../man/dpkg-buildpackage.1:259
> -"Preprocessor flags which are passed to the debian build system and can/"
> +"Preprocessor flags which are passed to the Debian build system and can/"

> -"B"
> +"B.)"

> #: ../../man/dpkg-buildpackage.1:246
> -msgid "Same as B for Fortran sources."
> +msgid "Same as B for Fortran sources."

> #: ../../man/dpkg-checkbuilddeps.1:33
> -"debian/control file."
> +"I file."

Fixed all these.

> #: ../../man/dpkg-genchanges.1:85
> Here I noticed that for some man pages you use B<> to denote file
> names, while for others you use I<>. This possibly should be unified.

I'll put this in my TODO for the man pages and take a look later.

> #: ../../man/start-stop-daemon.8:192
> -"specify a group by appending a B<:>, then the group or gid in the same way "
> +"specify a group by appending a B<:>, then describe the group or gid in the 
> same way "

I don't think this change is correct either.

Thanks for spotting those! they are now fixed in git.

regards,
guillem


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

Re: Typos in dpkg man pages

[Russ Allbery]

Guillem Jover <[EMAIL PROTECTED]> writes:

>> #:../../man/dpkg-buildpackage.1:145
>> -(for example by using B as 
>> I)
>> +(for example by calling B to build the 
>> package)
>
> I don't think this change is correct, as here it's referring to it as
> an argument to a command line option.

For what it's worth, the standard POD markup to use for the make example
here is C<>, not B<>.

>> -"O2> , or B<-g\\ -O0> if B is specified in DEB_BUILD_OPTIONS). "
>> +"O2>, or B<-g\\ -O0> if B is specified in DEB_BUILD_OPTIONS). "

C<> here as well, conventionally, for the flags.

>> #: ../../man/dpkg-checkbuilddeps.1:33
>> -"debian/control file."
>> +"I file."
>
> Fixed all these.

File names are conventionally F<>, not I<>.

>> #: ../../man/dpkg-genchanges.1:85
>> Here I noticed that for some man pages you use B<> to denote file
>> names, while for others you use I<>. This possibly should be unified.
>
> I'll put this in my TODO for the man pages and take a look later.

Conventionally, you'd change both to F<>.

>> #: ../../man/start-stop-daemon.8:192
>> -"specify a group by appending a B<:>, then the group or gid in the same way 
>> "
>> +"specify a group by appending a B<:>, then describe the group or gid in the 
>> same way "

C<> here.

Note that all of the comments above are just if you want to follow the
conventions used in Perl documentation and documented in the POD
specification.  If you're intentionally using a different markup
convention, please feel free to ignore these comments.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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