On Sat, Mar 31, 2007 at 01:08:08AM -0400, Geoffroy VALLEE wrote:
> This first patch only concerns the file debian/control.arch.in, i will send
> a patch for debian/control.in and then debian/rules if this one is
> acceptable.
Patches shouldn't be per-file, they should be per-change. For example,
one patch that touches all necessary files with a description "This
patch adds the initrd-template package" is reasonable. On the other
hand, a patch that does multiple things (renames systemimager-boot
*and* adds initrd-template) or a patch that only does only part of a
change (changes to control.arch.in to rename boot package) is not.
The reason is that we want to represent each logical change in a
single changeset. This makes it easier to do standard operations like
merging and reverting. It also means that the source *should* be
useful (buildable before and after the changeset).
> Note that i changed the name of the existing package (i.e. from
> systemimager-boot-${misc:Package-Arch}-standard to
> systemimager-${misc:Package-Arch}boot-standard only because this is the way
> RPMs for systemimager are currently named and it is quite nice for me to have
> the same naming pattern for both RPMs and Debian packages for the OSCAR
> project.
This complicates the upgrade path, and we would have to add
Conflicts/Replaces/Provides settings for each of these packages to
make it work. I don't think consistency with the RPMs is enough of a
justification for that. That also means that I'd prefer the
initrd-template packages be called
'systemimager-initrd-template-$arch' to be internally consistent.
> Index: control.arch.in
> ===================================================================
> --- control.arch.in (r?vision 1)
> +++ control.arch.in (r?vision 11)
> @@ -1,5 +1,5 @@
>
> -Package: systemimager-boot-${misc:Package-Arch}-standard
> +Package: systemimager-${misc:Package-Arch}boot-standard
> Architecture: all
> Recommends: systemimager-server
> Conflicts: systemimager-bin-${misc:Package-Arch},
> systemimager-kernel-${misc:Package-Arch},
> systemimager-initrd-${misc:Package-Arch},
> systemimager-boot-standard-${misc:Package-Arch},
> systemimager-ssh-${misc:Package-Arch}, systemimager-server (<< 3.6.3),
> systemimager-server (>= 3.6.4)
> @@ -12,3 +12,26 @@
> .
> This package contains the standard flavor of the boot files for installing
> ${misc:Package-Arch} machines. This package should be installed on the
> image server.
> +
> +Package: systemimager-${misc:Package-Arch}initrd-template
> +Architecture: all
> +Depends: systemimager-client (>=3.8.0-1)
Why does this depend on -client and not the other way around?
> +Description: SystemImager is software that automates Linux installs, software
> + distribution, and production deployment. SystemImager makes it
> easy to
You've combined the 'short' and 'long' description fields here. The
first line should be the 'short' description, and the subsequent lines
are the 'long' description. (See other packages as an example).
> + do installs, software distribution, content or data distribution,
> + configuration changes, and operating system updates to your network of
> + Linux machines. You can even update from one Linux release version to
> + another! It can also be used to ensure safe production deployments.
> + By saving your current production image before updating to your new
> + production image, you have a highly reliable contingency mechanism. If
> + the new production enviroment is found to be flawed, simply roll-back
> + to the last production image with a simple update command! Some
> + typical environments include: Internet server farms, database server
> + farms, high performance clusters, computer labs, and corporate desktop
> + environments.
For consistency, I think we should keep the first paragraph the same
for all packages. In a changeset that just adds this package, you
should use the existing first paragraph from all of the other
packages. If you'd like to change this description, please send a
changeset that changes the description for every package.
However, keep in mind that the description is what is used when doing
searches, so keywords are important. 'rsync' and 'multicast' are two
keyword regressions in the above description vs. the one we are
currently using. We also want to make sure not to regress any
description bugs we've fixed in the past, including #176973, #295734,
#309521, #277256, and #186932.
Thanks Geoffroy!
--
dann frazier
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
sisuite-devel mailing list
sisuite-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
