Re: RFS schoolbell - A calenaring server for schools

[Russ Allbery]

Peter Karlsson <[EMAIL PROTECTED]> writes:
> Matthew Palmer:

>> I just had another thought -- make a -1 revision with an empty
>> diff. Weird, but I can't think of any reason why it wouldn't work...

> That usually works just fine, and it what I do when I release jwhois,
> since I have also been doing the upstream releases.

Yup, it works well for me too.

> This works fine when you can control the upstream releases. You just
> need to ensure that no upstream releases are made with incorrect or
> outdated debian subdirs, it's better to have such releases lack the
> debian subdir completely.

The way I handle things, as a release procedure, is that I'll release new
Debian-specific versions (-2, -3, etc.) when the changes are only in the
debian directory, but for anything that affects the rest of the package,
I'll release a new upstream version.  I figure that if it's important
enough to release a new Debian package, it's important enough to release a
new upstream release too, and just make it clear to people in the release
notes whether it's a bug fix they're likely to care about.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFS schoolbell - A calenaring server for schools

[Russ Allbery]

Peter Karlsson <[EMAIL PROTECTED]> writes:
> Matthew Palmer:

>> I just had another thought -- make a -1 revision with an empty
>> diff. Weird, but I can't think of any reason why it wouldn't work...

> That usually works just fine, and it what I do when I release jwhois,
> since I have also been doing the upstream releases.

Yup, it works well for me too.

> This works fine when you can control the upstream releases. You just
> need to ensure that no upstream releases are made with incorrect or
> outdated debian subdirs, it's better to have such releases lack the
> debian subdir completely.

The way I handle things, as a release procedure, is that I'll release new
Debian-specific versions (-2, -3, etc.) when the changes are only in the
debian directory, but for anything that affects the rest of the package,
I'll release a new upstream version.  I figure that if it's important
enough to release a new Debian package, it's important enough to release a
new upstream release too, and just make it clear to people in the release
notes whether it's a bug fix they're likely to care about.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Brian Sutherland ([EMAIL PROTECTED]) wrote:
> On Thu, Sep 02, 2004 at 11:08:48PM +0200, Brian Sutherland wrote:
> > On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> > > .so files?  Should it be libschoolbell and libschoolbell-dev?
> > 
> > Indeed.
> 
> These few .so files are imported from zope and maybe slightly modified.
> So there is probably no use for people to build against them. 
> Would a -dev be required?

Hrm, I suppose probably not..  The -dev is for header files (mainly,
really) and if there aren't any (because it's not meant to be built
against) then I suppose it's reasonable to not have one.

Make sure to figure out what kind of relationship there is between the
.so (Is it really .so, or .so.1.2.123 or something?) and the binaries
that link against it.  Do the versions have to match exactly?  How do
you handle ABI changes to the .so?

Stephen


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Brian Sutherland ([EMAIL PROTECTED]) wrote:
> On Thu, Sep 02, 2004 at 11:08:48PM +0200, Brian Sutherland wrote:
> > On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> > > .so files?  Should it be libschoolbell and libschoolbell-dev?
> > 
> > Indeed.
> 
> These few .so files are imported from zope and maybe slightly modified.
> So there is probably no use for people to build against them. 
> Would a -dev be required?

Hrm, I suppose probably not..  The -dev is for header files (mainly,
really) and if there aren't any (because it's not meant to be built
against) then I suppose it's reasonable to not have one.

Make sure to figure out what kind of relationship there is between the
.so (Is it really .so, or .so.1.2.123 or something?) and the binaries
that link against it.  Do the versions have to match exactly?  How do
you handle ABI changes to the .so?

Stephen


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 11:08:48PM +0200, Brian Sutherland wrote:
> On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> > .so files?  Should it be libschoolbell and libschoolbell-dev?
> 
> Indeed.

These few .so files are imported from zope and maybe slightly modified.
So there is probably no use for people to build against them. 
Would a -dev be required?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> .so files?  Should it be libschoolbell and libschoolbell-dev?

Indeed.

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Brian Sutherland ([EMAIL PROTECTED]) wrote:
> On Thu, Sep 02, 2004 at 12:57:46PM -0400, Stephen Frost wrote:
> > I agree with this.  Really, debian-native packages are debian-specific
> > packages.  I would strongly encourage you to *not* make this a
> > debian-native package.
> 
> Thanks to you and the others on the list, now that I understand 
> the situation better I realize that this makes my life *much* easier.
> 
> However, I have another question. I can move almost everything to 
> schoolbell-common, the only things that are left in the schoolbell
> package are a few .so files. Would it make more sense rather to 
> create a schoolbell-dep package with only the architecture few
> dependent files?
> 
> Would -dep be the right suffex?

.so files?  Should it be libschoolbell and libschoolbell-dev?

Stephen


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 12:57:46PM -0400, Stephen Frost wrote:
> I agree with this.  Really, debian-native packages are debian-specific
> packages.  I would strongly encourage you to *not* make this a
> debian-native package.

Thanks to you and the others on the list, now that I understand 
the situation better I realize that this makes my life *much* easier.

However, I have another question. I can move almost everything to 
schoolbell-common, the only things that are left in the schoolbell
package are a few .so files. Would it make more sense rather to 
create a schoolbell-dep package with only the architecture few
dependent files?

Would -dep be the right suffex?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander

Re: RFS schoolbell - A calenaring server for schools

[Peter Karlsson]

Matthew Palmer:

I just had another thought -- make a -1 revision with an empty diff. 
Weird, but I can't think of any reason why it wouldn't work...


That usually works just fine, and it what I do when I release jwhois, since 
I have also been doing the upstream releases. The debian subdirectory is in 
the main cvs archive, but on a "hidden" branch. This means that if I am the 
one that release the upstream version, it gets a debian subdir, and the -1 
has an empty diff, but if the other maintainer releases it, it goes without 
a debian subdir, and the -1 will have a normal diff.


Any -2 will have a small diff adding the changes between -1 and -2.

This works fine when you can control the upstream releases. You just need to 
ensure that no upstream releases are made with incorrect or outdated debian 
subdirs, it's better to have such releases lack the debian subdir completely.


--
\\//
Peter - http://www.softwolves.pp.se/
  I do not read or respond to mail with HTML attachments.

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 11:08:48PM +0200, Brian Sutherland wrote:
> On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> > .so files?  Should it be libschoolbell and libschoolbell-dev?
> 
> Indeed.

These few .so files are imported from zope and maybe slightly modified.
So there is probably no use for people to build against them. 
Would a -dev be required?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander


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

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 04:48:37PM -0400, Stephen Frost wrote:
> .so files?  Should it be libschoolbell and libschoolbell-dev?

Indeed.

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander


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

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Brian Sutherland ([EMAIL PROTECTED]) wrote:
> On Thu, Sep 02, 2004 at 12:57:46PM -0400, Stephen Frost wrote:
> > I agree with this.  Really, debian-native packages are debian-specific
> > packages.  I would strongly encourage you to *not* make this a
> > debian-native package.
> 
> Thanks to you and the others on the list, now that I understand 
> the situation better I realize that this makes my life *much* easier.
> 
> However, I have another question. I can move almost everything to 
> schoolbell-common, the only things that are left in the schoolbell
> package are a few .so files. Would it make more sense rather to 
> create a schoolbell-dep package with only the architecture few
> dependent files?
> 
> Would -dep be the right suffex?

.so files?  Should it be libschoolbell and libschoolbell-dev?

Stephen


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Frank Küster]

Brian Sutherland <[EMAIL PROTECTED]> wrote:

Subject: Re: RFS schoolbell - A calenaring server for schools

s/calenar/calendar/, or is this a new english word?

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 12:57:46PM -0400, Stephen Frost wrote:
> I agree with this.  Really, debian-native packages are debian-specific
> packages.  I would strongly encourage you to *not* make this a
> debian-native package.

Thanks to you and the others on the list, now that I understand 
the situation better I realize that this makes my life *much* easier.

However, I have another question. I can move almost everything to 
schoolbell-common, the only things that are left in the schoolbell
package are a few .so files. Would it make more sense rather to 
create a schoolbell-dep package with only the architecture few
dependent files?

Would -dep be the right suffex?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander


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

Re: RFS schoolbell - A calenaring server for schools

[Peter Karlsson]

Matthew Palmer:
I just had another thought -- make a -1 revision with an empty diff. 
Weird, but I can't think of any reason why it wouldn't work...
That usually works just fine, and it what I do when I release jwhois, since 
I have also been doing the upstream releases. The debian subdirectory is in 
the main cvs archive, but on a "hidden" branch. This means that if I am the 
one that release the upstream version, it gets a debian subdir, and the -1 
has an empty diff, but if the other maintainer releases it, it goes without 
a debian subdir, and the -1 will have a normal diff.

Any -2 will have a small diff adding the changes between -1 and -2.
This works fine when you can control the upstream releases. You just need to 
ensure that no upstream releases are made with incorrect or outdated debian 
subdirs, it's better to have such releases lack the debian subdir completely.

--
\\//
Peter - http://www.softwolves.pp.se/
  I do not read or respond to mail with HTML attachments.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS schoolbell - A calenaring server for schools

[Matt Brubeck]

Stephen Frost wrote:

> I agree with this.  Really, debian-native packages are debian-specific
> packages.  I would strongly encourage you to *not* make this a
> debian-native package.

I also agree.  I am both upstream and Debian maintainer for my package,
and I find that a non-native package has many advantages:

 * We don't need to make a new "upstream" tarball for changes that only
   affect Debian.

 * Each Debian package is clearly based on a specific, cross-platform
   upstream version.

 * Non-native packages make it slightly easier for other Debian
   developers to make changes and NMUs.

 * If the upstream source tarball contains the "official" Debian
   directory, users who compile their own versions from tarballs or CVS
   will generate .debs with the same versions as the official packages.

If you do want to maintain your "debian" directory in the upstream
source, I suggest you use one of these strategies:

 1. Maintain the debian directory in the upstream CVS, but strip it out
when you generate release tarballs.  Use the .diff.gz to restore it
in the Debian source package.

 2. Maintain the debian directory in the upstream source, but use
"unofficial" versions and control files.  Replace them with the
official versions in the .diff.gz.

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Kevin B. McCarty ([EMAIL PROTECTED]) wrote:
> Matthew Palmer wrote:
> 
> > I just had another thought -- make a -1 revision with an empty diff.  Weird,
> > but I can't think of any reason why it wouldn't work...
> 
> Why would the diff be empty?  I would think it should contain the debian
> subdir in any case.  It makes no sense to ship a debian directory in
> generic source code released for RedHat, Windows, etc. (it would just
> uselessly increase the tarball size) so it might as well go into the
> Debian-specific diff.gz.
> 
> Even as both upstream and maintainer, you (Brian Sutherland) might find
> it useful to keep Debian packaging stuff separate from the main body of
> code.  Then if there is a bug in debian/rules, or Debian Policy is
> updated to mandate some new control field, you don't have to release an
> entirely new tarball just to fix a Debian-specific issue.

I agree with this.  Really, debian-native packages are debian-specific
packages.  I would strongly encourage you to *not* make this a
debian-native package.

Stephen


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Kevin B. McCarty]

Matthew Palmer wrote:

> I just had another thought -- make a -1 revision with an empty diff.  Weird,
> but I can't think of any reason why it wouldn't work...

Why would the diff be empty?  I would think it should contain the debian
subdir in any case.  It makes no sense to ship a debian directory in
generic source code released for RedHat, Windows, etc. (it would just
uselessly increase the tarball size) so it might as well go into the
Debian-specific diff.gz.

Even as both upstream and maintainer, you (Brian Sutherland) might find
it useful to keep Debian packaging stuff separate from the main body of
code.  Then if there is a bug in debian/rules, or Debian Policy is
updated to mandate some new control field, you don't have to release an
entirely new tarball just to fix a Debian-specific issue.

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544

Re: RFS schoolbell - A calenaring server for schools

[Frank Küster]

Brian Sutherland <[EMAIL PROTECTED]> wrote:

Subject: Re: RFS schoolbell - A calenaring server for schools

s/calenar/calendar/, or is this a new english word?

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Re: RFS schoolbell - A calenaring server for schools

[Matt Brubeck]

Stephen Frost wrote:

> I agree with this.  Really, debian-native packages are debian-specific
> packages.  I would strongly encourage you to *not* make this a
> debian-native package.

I also agree.  I am both upstream and Debian maintainer for my package,
and I find that a non-native package has many advantages:

 * We don't need to make a new "upstream" tarball for changes that only
   affect Debian.

 * Each Debian package is clearly based on a specific, cross-platform
   upstream version.

 * Non-native packages make it slightly easier for other Debian
   developers to make changes and NMUs.

 * If the upstream source tarball contains the "official" Debian
   directory, users who compile their own versions from tarballs or CVS
   will generate .debs with the same versions as the official packages.

If you do want to maintain your "debian" directory in the upstream
source, I suggest you use one of these strategies:

 1. Maintain the debian directory in the upstream CVS, but strip it out
when you generate release tarballs.  Use the .diff.gz to restore it
in the Debian source package.

 2. Maintain the debian directory in the upstream source, but use
"unofficial" versions and control files.  Replace them with the
official versions in the .diff.gz.


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

Re: RFS schoolbell - A calenaring server for schools

[Stephen Frost]

* Kevin B. McCarty ([EMAIL PROTECTED]) wrote:
> Matthew Palmer wrote:
> 
> > I just had another thought -- make a -1 revision with an empty diff.  Weird,
> > but I can't think of any reason why it wouldn't work...
> 
> Why would the diff be empty?  I would think it should contain the debian
> subdir in any case.  It makes no sense to ship a debian directory in
> generic source code released for RedHat, Windows, etc. (it would just
> uselessly increase the tarball size) so it might as well go into the
> Debian-specific diff.gz.
> 
> Even as both upstream and maintainer, you (Brian Sutherland) might find
> it useful to keep Debian packaging stuff separate from the main body of
> code.  Then if there is a bug in debian/rules, or Debian Policy is
> updated to mandate some new control field, you don't have to release an
> entirely new tarball just to fix a Debian-specific issue.

I agree with this.  Really, debian-native packages are debian-specific
packages.  I would strongly encourage you to *not* make this a
debian-native package.

Stephen


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Kevin B. McCarty]

Matthew Palmer wrote:

> I just had another thought -- make a -1 revision with an empty diff.  Weird,
> but I can't think of any reason why it wouldn't work...

Why would the diff be empty?  I would think it should contain the debian
subdir in any case.  It makes no sense to ship a debian directory in
generic source code released for RedHat, Windows, etc. (it would just
uselessly increase the tarball size) so it might as well go into the
Debian-specific diff.gz.

Even as both upstream and maintainer, you (Brian Sutherland) might find
it useful to keep Debian packaging stuff separate from the main body of
code.  Then if there is a bug in debian/rules, or Debian Policy is
updated to mandate some new control field, you don't have to release an
entirely new tarball just to fix a Debian-specific issue.

regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544


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

Re: RFS schoolbell - A calenaring server for schools

[Matthew Palmer]

On Thu, Sep 02, 2004 at 02:06:14PM +0200, Brian Sutherland wrote:
> On Thu, Sep 02, 2004 at 09:12:39PM +1000, Matthew Palmer wrote:
> > On the whole, I think you've made a poor compromise.  I would suggest
> > picking one way or the other, and going all the way with it.  As it stands,
> > you're going to have trouble uploading a -2 of anything without a new
> > upstream tarball anyway, so you're best off just going full-native and being
> > done with it.
> 
> Ok, so then a .dx (x = version number)attached to the relevant upstream 
> version indicating the debian specific branch? I am worried about the 
> resulting confusion because I should not bump the main projects version 
> for debian specific changes.
> 
> Could confuse Windows users:) "Why does debian have a bigger version?"

What about when you make a release that fixes a critical bug that only
manifests itself on Windows?  "Why does Windows have a bigger version?"

Two options: bump the subpatch version, or tack a .dx version on when you
need to fix the debian packaging.

You could always just handle Debian changes the same way you would with
any other changes -- make a new upstream release whenever there's a bug big
enough to warrant it, otherwise just put it into the next regular release.

I just had another thought -- make a -1 revision with an empty diff.  Weird,
but I can't think of any reason why it wouldn't work...

- Matt


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 09:12:39PM +1000, Matthew Palmer wrote:
> On the whole, I think you've made a poor compromise.  I would suggest
> picking one way or the other, and going all the way with it.  As it stands,
> you're going to have trouble uploading a -2 of anything without a new
> upstream tarball anyway, so you're best off just going full-native and being
> done with it.

Ok, so then a .dx (x = version number)attached to the relevant upstream 
version indicating the debian specific branch? I am worried about the 
resulting confusion because I should not bump the main projects version 
for debian specific changes.

Could confuse Windows users:) "Why does debian have a bigger version?"

> 
> > I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
> > And will get bigger.
> 
> Split it out, then.  Make a "schoolbell-common" package with all of this
> common stuff.  I thought it was a Python thing anyway -- why's it arch-dep?

It has a little C in it. But good point, i'll have a look into a
schooltool-common package.

> 
> > W: schoolbell: description-synopsis-might-not-be-phrased-properly
> > Huh?
> 
> The -i option to lintian is your friend whenever you get that Huh? feeling. 

Offending full stop removed. Indeed it was not a full sentence. Next
time I will do the obvious. 

> Not quite sure how that relates to your particular case, though -- the
> description in the .changes I just looked at didn't have an ending period...

Any rules/conventions on that?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander

Re: RFS schoolbell - A calenaring server for schools

[Matthew Palmer]

On Thu, Sep 02, 2004 at 12:52:55PM +0200, Brian Sutherland wrote:
> W: schoolbell source: native-package-with-dash-version
> The package releases for more than just debian. And sometimes it will be 
> necessary to adjust the package only for debian but the debian directory
> is in the repository. So I think it makes no sense to move everything
> around again and a dash version is the most logical solution?

You'll get differing opinions about this.  On the one hand, since you're
apparently involved in upstream development anyway, there's not much point
in making separated releases.  Distinctly, being "Debian native" has certain
"this is really only for Debian" connotations that will likely get you into
trouble.

On the whole, I think you've made a poor compromise.  I would suggest
picking one way or the other, and going all the way with it.  As it stands,
you're going to have trouble uploading a -2 of anything without a new
upstream tarball anyway, so you're best off just going full-native and being
done with it.

> I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
> And will get bigger.

Split it out, then.  Make a "schoolbell-common" package with all of this
common stuff.  I thought it was a Python thing anyway -- why's it arch-dep?

> W: schoolbell: description-synopsis-might-not-be-phrased-properly
> Huh?

The -i option to lintian is your friend whenever you get that Huh? feeling. 
In this case:

Tag: description-synopsis-might-not-be-phrased-properly
Type: warning
Info: The synopsis (first line in the package "Description:" field, the
 short description) ends with a full stop "." character. This is not
 necessary, as the synopsis doesn't need to be a full sentence. It is
 recommended that a descriptive phrase is used instead.
 .
 Note also that the synopsis is not part of the rest of the "Description:"
 field.
Ref: policy 3.4.1

Not quite sure how that relates to your particular case, though -- the
description in the .changes I just looked at didn't have an ending period...

- Matt


signature.asc
Description: Digital signature

RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

I am packaging schoolbell on behalf of upstream (Related to ITP#263088)
and seeking a sponsor.

Schoolbell is the first publicly available version of the Schooltool
server and is a stripped down version that only deals with 
calendaring and scheduling between groups.

This is the first wider release that people can actually test (The other
schooltool packages should follow soon).

Advertising plug for Schooltool:
Schooltool[1] is a project to develop an open source administration suite
for schools. It is privately funded by the shuttleworth foundation[2] and
arose out of a need for better governance of schools in South Africa
that do not have the resources for more expensive products. It is firmly
GPL with some imports from Zope (ZPL 2 or greater).

Personal opinion:
If we can improve the administration and management of schools,
especially in poor countries, even a little bit, that would be a very 
good thing.

The packages can be found here:

http://www.schooltool.org/Members/jinty/debian_packaging/packaging_home/document_view


The package is NOT lintian clean, but i will attempt to explain away the
remaining warnings:

W: schoolbell source: native-package-with-dash-version
The package releases for more than just debian. And sometimes it will be 
necessary to adjust the package only for debian but the debian directory
is in the repository. So I think it makes no sense to move everything
around again and a dash version is the most logical solution?

I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
And will get bigger.

W: schoolbell: description-synopsis-might-not-be-phrased-properly
Huh?

[1] www.schooltool.org
[2] http://www.tsf.org.za/

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander

Re: RFS schoolbell - A calenaring server for schools

[Matthew Palmer]

On Thu, Sep 02, 2004 at 02:06:14PM +0200, Brian Sutherland wrote:
> On Thu, Sep 02, 2004 at 09:12:39PM +1000, Matthew Palmer wrote:
> > On the whole, I think you've made a poor compromise.  I would suggest
> > picking one way or the other, and going all the way with it.  As it stands,
> > you're going to have trouble uploading a -2 of anything without a new
> > upstream tarball anyway, so you're best off just going full-native and being
> > done with it.
> 
> Ok, so then a .dx (x = version number)attached to the relevant upstream 
> version indicating the debian specific branch? I am worried about the 
> resulting confusion because I should not bump the main projects version 
> for debian specific changes.
> 
> Could confuse Windows users:) "Why does debian have a bigger version?"

What about when you make a release that fixes a critical bug that only
manifests itself on Windows?  "Why does Windows have a bigger version?"

Two options: bump the subpatch version, or tack a .dx version on when you
need to fix the debian packaging.

You could always just handle Debian changes the same way you would with
any other changes -- make a new upstream release whenever there's a bug big
enough to warrant it, otherwise just put it into the next regular release.

I just had another thought -- make a -1 revision with an empty diff.  Weird,
but I can't think of any reason why it wouldn't work...

- Matt


signature.asc
Description: Digital signature

Re: RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

On Thu, Sep 02, 2004 at 09:12:39PM +1000, Matthew Palmer wrote:
> On the whole, I think you've made a poor compromise.  I would suggest
> picking one way or the other, and going all the way with it.  As it stands,
> you're going to have trouble uploading a -2 of anything without a new
> upstream tarball anyway, so you're best off just going full-native and being
> done with it.

Ok, so then a .dx (x = version number)attached to the relevant upstream 
version indicating the debian specific branch? I am worried about the 
resulting confusion because I should not bump the main projects version 
for debian specific changes.

Could confuse Windows users:) "Why does debian have a bigger version?"

> 
> > I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
> > And will get bigger.
> 
> Split it out, then.  Make a "schoolbell-common" package with all of this
> common stuff.  I thought it was a Python thing anyway -- why's it arch-dep?

It has a little C in it. But good point, i'll have a look into a
schooltool-common package.

> 
> > W: schoolbell: description-synopsis-might-not-be-phrased-properly
> > Huh?
> 
> The -i option to lintian is your friend whenever you get that Huh? feeling. 

Offending full stop removed. Indeed it was not a full sentence. Next
time I will do the obvious. 

> Not quite sure how that relates to your particular case, though -- the
> description in the .changes I just looked at didn't have an ending period...

Any rules/conventions on that?

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander


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

Re: RFS schoolbell - A calenaring server for schools

[Matthew Palmer]

On Thu, Sep 02, 2004 at 12:52:55PM +0200, Brian Sutherland wrote:
> W: schoolbell source: native-package-with-dash-version
> The package releases for more than just debian. And sometimes it will be 
> necessary to adjust the package only for debian but the debian directory
> is in the repository. So I think it makes no sense to move everything
> around again and a dash version is the most logical solution?

You'll get differing opinions about this.  On the one hand, since you're
apparently involved in upstream development anyway, there's not much point
in making separated releases.  Distinctly, being "Debian native" has certain
"this is really only for Debian" connotations that will likely get you into
trouble.

On the whole, I think you've made a poor compromise.  I would suggest
picking one way or the other, and going all the way with it.  As it stands,
you're going to have trouble uploading a -2 of anything without a new
upstream tarball anyway, so you're best off just going full-native and being
done with it.

> I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
> And will get bigger.

Split it out, then.  Make a "schoolbell-common" package with all of this
common stuff.  I thought it was a Python thing anyway -- why's it arch-dep?

> W: schoolbell: description-synopsis-might-not-be-phrased-properly
> Huh?

The -i option to lintian is your friend whenever you get that Huh? feeling. 
In this case:

Tag: description-synopsis-might-not-be-phrased-properly
Type: warning
Info: The synopsis (first line in the package "Description:" field, the
 short description) ends with a full stop "." character. This is not
 necessary, as the synopsis doesn't need to be a full sentence. It is
 recommended that a descriptive phrase is used instead.
 .
 Note also that the synopsis is not part of the rest of the "Description:"
 field.
Ref: policy 3.4.1

Not quite sure how that relates to your particular case, though -- the
description in the .changes I just looked at didn't have an ending period...

- Matt


signature.asc
Description: Digital signature

RFS schoolbell - A calenaring server for schools

[Brian Sutherland]

I am packaging schoolbell on behalf of upstream (Related to ITP#263088)
and seeking a sponsor.

Schoolbell is the first publicly available version of the Schooltool
server and is a stripped down version that only deals with 
calendaring and scheduling between groups.

This is the first wider release that people can actually test (The other
schooltool packages should follow soon).

Advertising plug for Schooltool:
Schooltool[1] is a project to develop an open source administration suite
for schools. It is privately funded by the shuttleworth foundation[2] and
arose out of a need for better governance of schools in South Africa
that do not have the resources for more expensive products. It is firmly
GPL with some imports from Zope (ZPL 2 or greater).

Personal opinion:
If we can improve the administration and management of schools,
especially in poor countries, even a little bit, that would be a very 
good thing.

The packages can be found here:

http://www.schooltool.org/Members/jinty/debian_packaging/packaging_home/document_view


The package is NOT lintian clean, but i will attempt to explain away the
remaining warnings:

W: schoolbell source: native-package-with-dash-version
The package releases for more than just debian. And sometimes it will be 
necessary to adjust the package only for debian but the debian directory
is in the repository. So I think it makes no sense to move everything
around again and a dash version is the most logical solution?

I: schoolbell: arch-dep-package-has-big-usr-share 2543kB 45%
And will get bigger.

W: schoolbell: description-synopsis-might-not-be-phrased-properly
Huh?

[1] www.schooltool.org
[2] http://www.tsf.org.za/

-- 
Brian Sutherland

"There has got to be more to life than just being really,
really, really, ridiculously good-looking." -- Derek Zoolander


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