Le lundi 2 avril 2007 12:05, vous avez écrit :
> 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).
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.
>
> > 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.
>
> > 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?
Because this is a mistake. :-)
>
> > +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.
>
> > + 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.
>
> 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.
>
> Thanks Geoffroy!
Thanks for your feedback! :-)
--
Geoffroy
-------------------------------------------------------------------------
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
