DEP5: Let's calm down?

[Lars Wirzenius]

to, 2009-06-11 kello 18:18 +0200, Josselin Mouette kirjoitti:
> Le jeudi 11 juin 2009 à 16:16 +0300, Lars Wirzenius a écrit :
> > > - and a reason
> > 
> > That's the killer point we should concentrate on.
> [ ... ]
> 
> > Would Debian benefit from being able to easily query for things like
> > "packages linking to OpenSSL, licensed under GPL, but without an
> > exception"?
> 
> Wait… you don’t know of an existing reason and are trying to make up
> one?

*sigh*

Josselin, even when I agree with you, you alienate me. Well done.

To clarify: I know that there is a need for something like DEP5 by some
commercial derivatives of Debian, even if it isn't used by everyone,
having been told this by them. This is not a reason for Debian to do
DEP5. I suggested a possible other reason for Debian to want DEP5, with
the intention to see if anyone agreed with this. I'm not telling Debian
that this is a good reason to do DEP5. I'm looking for reasons to
continue work on DEP5, not giving those reasons.

I find that the machine readable debian/copyright file proposal has been
handled badly almost from the beginning. After the first couple of dozen
edits, the wiki page was a bad place to develop it, because it's
difficult to follow the discussion and also because it's hidden from
most developers. After it was moved to the DEP process, there has been
little attempt at building support and consensus, and way too much
attitude, by people for and against the issue.

In this situation, I don't think we, the Debian development community,
are able to discuss this in a reasonable manner. It may be that DEP5 has
no use and should be forgotten, but right now we cannot reliably decide
on that. The battle lines have been dug, insults are being fired, and
tempers are running hot. Any decision for or against DEP5 right now will
mostly be done in anger, and that's no way to handle technical debates.

I propose that we take a break, let tempers calm down, and see if we
can't have a reasoned, sensible discussion about whether DEP5 is
worthwhile a week from now.

PS. Just to make things extra clear: I am weakly in favor of DEP5 as an
optional thing for those who want to use it, and strongly opposed to
making it mandatory. I admit to not having a list of good reasons for
Debian to want DEP5, but I would like the opportunity to discuss
possible reasons without having to fight all the time. I'm perfectly
happy with Debian reaching a consensus that DEP5 is not worth the
effort, but I want it be given a reasonable chance. Right now, all
sensible people are staying far away from anything related to DEP5 to
avoid being dragged into the mud.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"

[Lars Wirzenius]

to, 2009-06-11 kello 11:47 -0700, Russ Allbery kirjoitti:
> Lars Wirzenius  writes:
> 
> > Would Debian benefit from being able to easily query for things like
> > "packages linking to OpenSSL, licensed under GPL, but without an
> > exception"?
> 
> Even with the DEP-5 copyright file, you can at most generate a candidate
> set that you still have to manually check.  There are packages with one
> GPL component that is not the component that's linked with OpenSSL.

That's very true. Getting the candidate set should be much easier with a
structured copyright file, though, as far as I can see.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian @Linuxtag 2009 - Last call for help

[Martin Alfke]

On Mon, May 25, 2009 at 11:36 AM, Alexander Wirt wrote:

> Hi,
>
> okay - this is my last call for help. Currently I have one, maybe two
> people
> that want to help on the Linuxtag [1] booth on June 24th - 26th [2] in
> Berlin, Germany. Linuxtag is the largest Linux and Open Source in Germany
> whith 10.000 expected visitors.
> I think that two people are not enough to run a booth. If this call for
> help does not succeed I'll have to cancel the booth. So if you are in
> Berlin
> during June 24th - 27th please be so kind and participate to the Debian
> booth. You don't have to be a Linux/Debian expert, just a little bit
> motivated :).
>

Hi,

is there still a need for more people?
At the moment I am checking whether I could attend Linuxtag on 24th and 25th
(half day only).

Regards,

Martin

Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"

[Michael Banck]

On Thu, Jun 11, 2009 at 08:32:44PM +0200, Mike Hommey wrote:
> Moreover, these "reasons" are all pretty pointless if the format is not made
> mandatory, which is supposedly not the goal.

Some of them might be less useful unless fully implemented, some of them
are certainly useful.


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#532858: ITP: vis5d+ -- Vis5d, a free OpenGL-based volumetric visualization program for scientific datasets in 3+ dimensions.

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: vis5d+
  Version : 1.2.0
  Upstream Author : Bill Hibbard
* URL : http://vis5d.sourceforge.net
* License : GPL
  Programming Lang: C
  Description : Vis5d, a free OpenGL-based volumetric visualization program 
for scientific datasets in 3+ dimensions.

Vis5d+ is intended as a central repository for enhanced versions and 
development work on Vis5d, a free OpenGL-based volumetric visualization program 
for scientific datasets in 3+ dimensions.

This project started out, with the blessing of the original Vis5d developers, 
as a conversion of Vis5d's build process to use GNU autoconf and 
automake. (Inspired by the difficulty of getting Vis5d to compile on the 
author's LinuxPPC PowerBook.) It quickly became apparent that many other 
enhancements were possible, and were of wide interest to users. Moreover, a 
large number of enhanced versions to Vis5d exist that have not been merged 
into the original Vis5d sources, due to time and resource limitations of the 
original developers, or to differences of opinion about design directions. 

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#532872: please provide links to the Debian Project patch tracking system

[Aníbal Monsalve Salazar]

Package: qa.debian.org
Severity: wishlist

http://patch-tracking.debian.net/

The web address of the Debian Project patch tracking system is above and
can also be reached using the web address below.

http://patches.debian.net/

Is there any plan to have links to packages in the web pages of the
package tracking system?

For example, at http://packages.qa.debian.org/rdate, I would like to see
a link to http://patch-tracking.debian.net/package/rdate



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#532872: please provide links to the Debian Project patch tracking system

[Aníbal Monsalve Salazar]

On Fri, Jun 12, 2009 at 09:21:27PM +1000, Anibal Monsalve Salazar wrote:
>Package: qa.debian.org
>Severity: wishlist
>
>http://patch-tracking.debian.net/
>
>The web address of the Debian Project patch tracking system is above and
>can also be reached using the web address below.
>
>http://patches.debian.net/
>
>Is there any plan to have links to packages in the web pages of the
>package tracking system?
>
>For example, at http://packages.qa.debian.org/rdate, I would like to see
>a link to http://patch-tracking.debian.net/package/rdate

There is a discussion about the patch tracking system at:

http://bugs.debian.org/482102


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"

[Russ Allbery]

Lars Wirzenius  writes:
> to, 2009-06-11 kello 11:47 -0700, Russ Allbery kirjoitti:

>> Even with the DEP-5 copyright file, you can at most generate a
>> candidate set that you still have to manually check.  There are
>> packages with one GPL component that is not the component that's
>> linked with OpenSSL.

> That's very true. Getting the candidate set should be much easier with
> a structured copyright file, though, as far as I can see.

I agree that it will at least be easier.  Lintian does an okay job with
pure-text heuristics, though.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#532923: ITP: aegir-provision -- backend of the Aegir hosting system

[The Anarcat]

Package: wnpp
Severity: wishlist
Owner: The Anarcat 


* Package name: aegir-provision
  Version : 0.2
  Upstream Author : Adrian Rossouw
* URL : http://drupal.org/project/provision
* License : GPL
  Programming Lang: PHP
  Description : backend of the Aegir hosting system

Ægir is a new set of contributed modules for Drupal that aims to
solve the problem of managing a large number of Drupal sites. It
does this by providing you with a simple Drupal based hosting front
end for your entire network of sites. To deploy a new site you
simply have to create a new Site node. To backup or upgrade sites,
you simply manage your site nodes as you would any other node.

The provision component of this system provides the back end used
for system level tasks such as creating configuration files and
managing databases and backup files.

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#532932: ITP: libalien-libjio-perl -- Perl package to find libjio

[Jonathan Yu]

Package: wnpp
Severity: wishlist
Owner: Jonathan Yu 


* Package name: libalien-libjio-perl
  Version : 1.0
  Upstream Author : Jonathan Yu 
* URL : CPAN
* License : Public Domain
  Programming Lang: Perl
  Description : Perl package to find libjio

This module is a generic Perl module that is designed to install libjio if it
is not installed, and then report the flags required for programs to link to
it. Under Debian, installing libjio via this package is not necessary (since
it can simply Build-Depend and Depend on the libjio package itself.

However, the Perl module still needs to be installed so that Perl programs can
find it, and the flags required to link to it. This will be useful if modules
other than simply IO::Journal (later to be ITP'd as libio-journal-perl, once
it is appropriately uploaded to CPAN).

Luckily, since only the Perl stuff is going to be installed, then it's not
likely we'll ever need to really upgrade this module...



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#532932: ITP: libalien-libjio-perl -- Perl package to find libjio

[brian m. carlson]

On Fri, Jun 12, 2009 at 05:14:29PM -0400, Jonathan Yu wrote:
> This module is a generic Perl module that is designed to install libjio if it
> is not installed, and then report the flags required for programs to link to
> it. Under Debian, installing libjio via this package is not necessary (since
> it can simply Build-Depend and Depend on the libjio package itself.
> 
> However, the Perl module still needs to be installed so that Perl programs can
> find it, and the flags required to link to it. This will be useful if modules
> other than simply IO::Journal (later to be ITP'd as libio-journal-perl, once
> it is appropriately uploaded to CPAN).
> 
> Luckily, since only the Perl stuff is going to be installed, then it's not
> likely we'll ever need to really upgrade this module...

Can't you just patch the modules in question so that they don't need to
use this module?  It seems silly to create a module just to make sure
that a dependency is installed.  That's for the Perl module building
system or dpkg to ensure.

If we had a separate Perl module to ensure every dependency that a Perl
module might need, we'd have lots of unnecessary modules.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#532932: ITP: libalien-libjio-perl -- Perl package to find libjio

[Jonathan Yu]

Brian:

On Fri, Jun 12, 2009 at 5:57 PM, brian m.
carlson wrote:
> On Fri, Jun 12, 2009 at 05:14:29PM -0400, Jonathan Yu wrote:
>> This module is a generic Perl module that is designed to install libjio if it
>> is not installed, and then report the flags required for programs to link to
>> it. Under Debian, installing libjio via this package is not necessary (since
>> it can simply Build-Depend and Depend on the libjio package itself.
>>
>> However, the Perl module still needs to be installed so that Perl programs 
>> can
>> find it, and the flags required to link to it. This will be useful if modules
>> other than simply IO::Journal (later to be ITP'd as libio-journal-perl, once
>> it is appropriately uploaded to CPAN).
>>
>> Luckily, since only the Perl stuff is going to be installed, then it's not
>> likely we'll ever need to really upgrade this module...
>
> Can't you just patch the modules in question so that they don't need to
> use this module?  It seems silly to create a module just to make sure
> that a dependency is installed.  That's for the Perl module building
> system or dpkg to ensure.
That is a very good point. However, I'm just not sure if other modules
will want to use Alien::Libjio -- it has a few methods that wrap
around pkg-config and ExtUtils::Liblist, so that you can get compile
flags and linker flags (that applications need to compile XS bindings
against libjio).

I did consider the idea of patching at first, but I wasn't sure that
would be good in the event that a module other than IO::Journal needs
that functionality. On the other hand, I suppose you are correct - for
Debian systems, we can always expect libjio to be in the right place,
and so this module might be unnecessary to package.

I'll need to think about this more. I did file the ITP but it's sort
of tentative, and I might retract it later pending further
review/discussion.

FYI it should be mentioned that there is at least one module which is
a precedent for this type of behaviour, see libalien-wxwidgets-perl.
We do have libwx-perl (the WxWidgets Perl Bindings), and we do have
the WxWidgets toolkit itself, so one could also argue for the same
thing with libalien-wxwidgets-perl.

Ideally, we'd figure out a (Perl package-specific) policy on what to
do about Alien:: modules.

I've attached the Debian-Perl group list too, so we'll probably end up
having a discussion there as well.
>
> If we had a separate Perl module to ensure every dependency that a Perl
> module might need, we'd have lots of unnecessary modules.

Thanks for the advice!

Cheers,

Jonathan


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"

[Wouter Verhelst]

On Thu, Jun 11, 2009 at 09:30:31AM -0700, Steve Langasek wrote:
> On Thu, Jun 11, 2009 at 06:10:56PM +0200, Mike Hommey wrote:
> > If the sole purpose of the format is to have a machine-parseable format,
> > if it doesn't apply to all packages, then the fact that it is
> > machine-parseable is useless, because you won't be able to machine-parse
> > all copyright information from all packages.
> 
> Let's remove all "should"s from policy, then, since evidently anything that
> we don't have 100% compliance with is useless.

Certainly not. However, I do think that anything which does not _aim_
for eventual 100% compliance is useless.

I'm finding it difficult to believe the argument "oh, but this isn't
going to be mandatory". While I can think of a few use cases wherein
not having a machine-parsable format for debian/copyright be mandatory
can be useful, I can think of a lot more use cases wherein a such a
requirement would be a serious improvement to the usefulness of the
actual proposal.

If we're going to make a machine-parsable format, at least make it
something which can be usefully used in all our packages.

Otherwise, I'm pretty sure that the following is going to happen:
- At some undetermined point in the future, the proposal is finalized
  and accepted
- Some percentage of packages have their debian/copyright file converted
  to the new format
- At some other point in the future, someone figures that this
  debian/copyright file is an interesting candiate to do something
  useful.
- A while later, this person (or someone who uses the "something useful"
  written by that person) decides that the "oldfashioned" way should go
  out, and starts taking steps to make the machine-parsable format
  mandatory.
- Maintainers of large packages have to spend most of their time
  updating copyright files because nobody bothered to make the format a
  decent one today.

Please, if you're going to pursue this, make sure it's either acceptable
to everyone, or not even attempted in the first place.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#532932: ITP: libalien-libjio-perl -- Perl package to find libjio

[Ryan Niebur]

On Fri, Jun 12, 2009 at 07:29:40PM -0400, Jonathan Yu wrote:
> Brian:
> 
> On Fri, Jun 12, 2009 at 5:57 PM, brian m.
> carlson wrote:
> > On Fri, Jun 12, 2009 at 05:14:29PM -0400, Jonathan Yu wrote:
> >> This module is a generic Perl module that is designed to install libjio if 
> >> it
> >> is not installed, and then report the flags required for programs to link 
> >> to
> >> it. Under Debian, installing libjio via this package is not necessary 
> >> (since
> >> it can simply Build-Depend and Depend on the libjio package itself.
> >>
> >> However, the Perl module still needs to be installed so that Perl programs 
> >> can
> >> find it, and the flags required to link to it. This will be useful if 
> >> modules
> >> other than simply IO::Journal (later to be ITP'd as libio-journal-perl, 
> >> once
> >> it is appropriately uploaded to CPAN).
> >>
> >> Luckily, since only the Perl stuff is going to be installed, then it's not
> >> likely we'll ever need to really upgrade this module...
> >
> > Can't you just patch the modules in question so that they don't need to
> > use this module?  It seems silly to create a module just to make sure
> > that a dependency is installed.  That's for the Perl module building
> > system or dpkg to ensure.
> That is a very good point. However, I'm just not sure if other modules
> will want to use Alien::Libjio -- it has a few methods that wrap
> around pkg-config and ExtUtils::Liblist, so that you can get compile
> flags and linker flags (that applications need to compile XS bindings
> against libjio).
> 

you meantion that other modules may want to use it...well, then lets
deal with packaging that when this happens. there's no reason to right
now.

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Re: Bug#532932: ITP: libalien-libjio-perl -- Perl package to find libjio

[Jonathan Yu]

Hm, fair enough. I'll close the bug; and will not package the Alien module.

This also makes me wonder though, should a similar fate befall
libalien-wxwidgets-perl?

aven'jon(~/alien-jio/Alien-Libjio/t)> apt-cache rdepends libalien-wxwidgets-perl
libalien-wxwidgets-perl
Reverse Depends:
  libwx-perl

So if libwx-perl is patched, then libalien-wxwidgets-perl could be
made obsolete... On the other hand, even if this isn't something we'd
like in the future, maybe we could set a policy for that. I'll e-mail
debian-policy in a few days (pending any further discussion on these
lists first - debian-devel and debian-perl) to get some clarification
on this.

Thanks :-)

Jonathan

On Fri, Jun 12, 2009 at 7:50 PM, Ryan Niebur wrote:
> On Fri, Jun 12, 2009 at 07:29:40PM -0400, Jonathan Yu wrote:
>> Brian:
>>
>> On Fri, Jun 12, 2009 at 5:57 PM, brian m.
>> carlson wrote:
>> > On Fri, Jun 12, 2009 at 05:14:29PM -0400, Jonathan Yu wrote:
>> >> This module is a generic Perl module that is designed to install libjio 
>> >> if it
>> >> is not installed, and then report the flags required for programs to link 
>> >> to
>> >> it. Under Debian, installing libjio via this package is not necessary 
>> >> (since
>> >> it can simply Build-Depend and Depend on the libjio package itself.
>> >>
>> >> However, the Perl module still needs to be installed so that Perl 
>> >> programs can
>> >> find it, and the flags required to link to it. This will be useful if 
>> >> modules
>> >> other than simply IO::Journal (later to be ITP'd as libio-journal-perl, 
>> >> once
>> >> it is appropriately uploaded to CPAN).
>> >>
>> >> Luckily, since only the Perl stuff is going to be installed, then it's not
>> >> likely we'll ever need to really upgrade this module...
>> >
>> > Can't you just patch the modules in question so that they don't need to
>> > use this module?  It seems silly to create a module just to make sure
>> > that a dependency is installed.  That's for the Perl module building
>> > system or dpkg to ensure.
>> That is a very good point. However, I'm just not sure if other modules
>> will want to use Alien::Libjio -- it has a few methods that wrap
>> around pkg-config and ExtUtils::Liblist, so that you can get compile
>> flags and linker flags (that applications need to compile XS bindings
>> against libjio).
>>
>
> you meantion that other modules may want to use it...well, then lets
> deal with packaging that when this happens. there's no reason to right
> now.
>
> --
> _
> Ryan Niebur
> ryanrya...@gmail.com
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkoy6dEACgkQMihv+PacasUXMwCfTC5i9PcNiJGxq26AGY6Jr5xF
> HDYAoNKQmdPoV9OkT62GzqM1n1koj3bg
> =+CrV
> -END PGP SIGNATURE-
>
>


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"

[Ben Finney]

Wouter Verhelst  writes:

> I'm finding it difficult to believe the argument "oh, but this isn't
> going to be mandatory".

I don't know anyone making the argument that there should *never* be a
mandatory machine-parseable ‘debian/copyright’ format. Rather, I see the
argument that we don't *currently* have such a format, and that no such
format should mandatory in the immediate future.

The path to achieving such a format that we can promote as mandatory
must, in my opinion, be through promoting it as an *optional* format,
and improving both the format and the acceptance of it. Such a path, if
it ever to reach a point where we can begin to promote making it
mandatory, necessarily passes through a point where those who don't
follow it voluntarily are in a small minority, and of those who don't
follow it, none have any respectable objection to it.

Any format that doesn't achieve that latter milestone has no business
being promoted as mandatory, IMO, and we're certainly a long way from
that point. So that can easily give the impression, I suppose, that
someone is saying “it's *never* going to be mandatory”, even when
AFAICT no-one has actually said that.

> Please, if you're going to pursue this, make sure it's either
> acceptable to everyone, or not even attempted in the first place.

I'm of the opinion that “acceptable to everyone” can only be
deomstrated by attempting it (even without knowing whether that can be
actieved) and trying to get many people using it for their packages
voluntarily.

-- 
 \“The right to search for truth implies also a duty; one must |
  `\  not conceal any part of what one has recognized to be true.” |
_o__) —Albert Einstein |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#532941: ITP: enma -- ENMA is a milter program for the domain authentication technologies.

[ARAKI Yasuhiro]

Package: wnpp
Severity: wishlist
Owner: ARAKI Yasuhiro 


* Package name: enma
  Version : 1.1.0
  Upstream Author : SUZUKI Takahiko  
* URL : http://sourceforge.net/projects/enma/
* License : BSD style.
  Programming Lang: C
  Description : ENMA is a milter program for the domain authentication 
technologies.

It authenticates sender's address with SPF and Sender ID, then
labels the result onto the Authentication-Results: field.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"

[Ben Finney]

Ben Finney  writes:

> Wouter Verhelst  writes:
> 
> > I'm finding it difficult to believe the argument "oh, but this isn't
> > going to be mandatory".
> 
> I don't know anyone making the argument that there should *never* be a
> mandatory machine-parseable ‘debian/copyright’ format.

Sorry, this is too broad; it should be: I don't know anyone promoting a
machine-parseable ‘debian/copyright’ format who makes the argument that
no such format should ever be mandatory.

-- 
 \  “Why should I care about posterity? What's posterity ever done |
  `\for me?” —Groucho Marx |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DEP-5: Please clarify the meaning of "same licence and share copyright holders"

[Steve Langasek]

On Sat, Jun 13, 2009 at 01:39:00AM +0200, Wouter Verhelst wrote:
> Certainly not. However, I do think that anything which does not _aim_
> for eventual 100% compliance is useless.

> I'm finding it difficult to believe the argument "oh, but this isn't
> going to be mandatory". While I can think of a few use cases wherein
> not having a machine-parsable format for debian/copyright be mandatory
> can be useful, I can think of a lot more use cases wherein a such a
> requirement would be a serious improvement to the usefulness of the
> actual proposal.

Is debhelper useless because it's not mandatory?

Are watch files useless because they're not mandatory?

Both are tools for normalizing the content of packages in ways that make it
easier for third parties to approach the source packages and do useful
things with them, with minimal effort and per-package learning curve.  I
think a machine-readable debian/copyright is something in the same spirit:
there are network effects that make it more useful the more widespread it
is, but there's no reason it should be mandatory in Debian unless there's a
clear consensus in favor of doing so.

If you accept that debhelper and watch files are useful without being
mandatory, surely you can see that a copyright file format could be useful
in the same way?

If you *don't* accept that debhelper and watch files are useful to people,
then I'm not inclined to try to persuade you that the current plan is useful
either.  Because, given that I'm *not* trying to make it mandatory, it's not
actually relevant to try to convince everyone that it's useful, just to
convince a substantial subset of people.

> If we're going to make a machine-parsable format, at least make it
> something which can be usefully used in all our packages.

Certainly, my intent is to make the machine-parseable format something which
is *suitable* for use in any package.  I welcome input on how best to
achieve this.  But I see no need to engage naysayers who question the
premise that a machine-parseable file has uses.

> Otherwise, I'm pretty sure that the following is going to happen:

[...]

> - A while later, this person (or someone who uses the "something useful"
>   written by that person) decides that the "oldfashioned" way should go
>   out, and starts taking steps to make the machine-parsable format
>   mandatory.

debhelper has been around for about a decade or so, and is not mandatory
even though it would make QA work quite a bit easier.  Mind, people have
*proposed* making it mandatory, and have been shot down.  Why wouldn't the
same happen to proposals to make an unsatisfactory copyright format
mandatory?

> - Maintainers of large packages have to spend most of their time
>   updating copyright files because nobody bothered to make the format a
>   decent one today.

Or they could engage the process productively at any time prior to this by
helping to fix its shortcomings; or failing that, they could participate in
the Policy process to prevent it becoming a standard.

And after all, debhelper didn't need a DEP at all in order to come into
widespread use, so your worst case scenario could equally well come to pass
without ever going through a public discussion process - there are already a
fair number of formatted debian/copyright files in the wild based on nothing
more than a pretty bad wiki draft...

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: The ‘read -r ’ bashism.

[Charles Plessy]

Le Tue, Jun 09, 2009 at 07:59:53PM -0700, Ben Pfaff a écrit :
> 
> Perhaps the fix is as simple as changing
> read
> to
> read REPLY.

Dear Ben, thank you very much.

Indeed, in the script found by checkbashisms, there is:

echo "To exit use Control C or press return to continue."
echo
echo "--"
read

which will fail if using dash as /bin/sh.

Have a nice week-end,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org