[Sisuite-devel] systemimager-debian, patch for control.arch.in

[Geoffroy VALLEE]

Hi all,

First patch for the creation of Debian packages that match the set of RPMs.
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.
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.

All comments are welcome. :-)

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)
+Description: SystemImager is software that automates Linux installs, software
+ distribution, and production deployment. SystemImager makes it easy to
+ 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.
+ .
+ The %{misc:Package-Arch}initrd_template package provides initrd template files
+ for creating custom ramdisk that works with a specific kernel by using UYOK
+ (Use Your Own Kernel). The custom ramdisk can then be used to boot and
+ install %{misc:Package-Arch} Linux machines during the SystemImager
+ autoinstall process.

[dann frazier]

Post by Geoffroy VALLEE
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).

Post by Geoffroy VALLEE
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.

Post by Geoffroy VALLEE
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?

Post by Geoffroy VALLEE
+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).

Post by Geoffroy VALLEE
+ 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!

[Geoffroy Vallée]

Post by dann frazier

Post by Geoffroy VALLEE
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).

Ok i understand that. I just thought that since these modifications were not
that critical it was not problem to submit them all together. I will change
that.

Post by dann frazier

Post by Geoffroy VALLEE
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.

But there is a point i do not understand (but it is not critical): Is Debian
package management totally decoupled from the RPMs? If so, i am kind of
surprised because if someone has to deal with both a Debian based system and
an RPM based system, that will be very confusing. But again, i am not an
expert it is just my personal feeling, i do not have any problem to not have
the same set of packages on Debian, i can update my modifications.

Post by dann frazier

Post by Geoffroy VALLEE
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),
.
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?

Because this is a mistake. :-)

Post by dann frazier

Post by Geoffroy VALLEE
+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).

I will fix that.

Post by dann frazier

Post by Geoffroy VALLEE
+ 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.

I have to admit that i had a look to the RPMs and i did a basic copy and
paste :-). I will modify my stuff based on your remarks.

Post by dann frazier
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.

Ok, i will check of these points.

Post by dann frazier
Thanks Geoffroy!

Thanks for your feedback! :-)

[dann frazier]

Post by Geoffroy Vallée
But there is a point i do not understand (but it is not critical): Is Debian
package management totally decoupled from the RPMs?

They are separate databases. You can not safely install RPMs on a
dpkg-managed system unless they are proper LSB RPMs that restrict
themselves to installing under /opt, etc. That's a corner-case though
that is rarely the best idea for free software.

[Geoffroy Vallée]

Post by dann frazier

Post by Geoffroy Vallée
But there is a point i do not understand (but it is not critical): Is
Debian package management totally decoupled from the RPMs?

They are separate databases. You can not safely install RPMs on a
dpkg-managed system unless they are proper LSB RPMs that restrict
themselves to installing under /opt, etc. That's a corner-case though
that is rarely the best idea for free software.

I was not clear, that was not my question. I was speaking only about the
naming pattern and not about installing RPMs on Debian systems. I am a Debian
user since a long time, i know that it is a bad idea to install RPMs even if
it is technically possible. :-)

But anyway my question was not that interesting, the current package names do
not bother me that much; i will just have to update OSCAR package
configuration file.