[Pkg-ace-devel] Bug#599549: Please review ace packages description
Justin B Rye
jbr at edlug.org.uk
Mon Jun 13 17:21:36 UTC 2011
Thomas Girard wrote:
> I believe there are separate issues in the current descriptions:
> 1. long description is not a sentence:
> libace-inet-*, tao-imr, tao-cosnaming, tao-costrading,
> tao-ftrtevent, tao-load, tao-tls
True, though not always easy to fix.
> 2. description does not explain what the package is for:
> ace-gperf, libtao-*, tao-ft
ace-gperf isn't bad, as long as it's allowed to lean on gperf's own
description. The TAO packages are fuzzier, since CORBA is hopelessly
difficult to explain in a hurry, but libraries are entitled to a bit
more of an assumption that "if you don't know then you don't need to
know".
> 3. descriptions look the same:
> libace-{qt,xt,tk,fl,fox}-reactor*
Boilerplate is fine as long as it's accompanied by a distinguishing
paragraph (as here).
> 4. unclear description:
> tao-notify
Are you sure you mean tao-notify (which is quite clear about being a
transitional package) and not tao-cosnotify? Though there's nothing
terribly bad about tao-cosnotify's description either, given that this
is CORBA.
> Do you agree with the above analysis? Anything missing? How to
> proceed then?
Well, there are quite a few other changes I'd apply if we were giving
it a standard d-l-e review...
> ---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---8<---
> Package: mpc-ace
> Architecture: all
> Depends: ${perl:Depends}, ${misc:Depends}
> Recommends: make
> Replaces: libace-dev (= 5.6.3-4)
> Suggests: libace-dev, pkg-config
> Description: makefile, project and workspace creator
> This package contains the Makefile, Project and Workspace Creator (MPC)
> as distributed with the ACE toolkit.
Serial comma:
s/makefile, project and workspace/makefile, project, and workspace/ig
> .
> MPC generates platform and compiler specific files to automate the
> compilation process.
s/platform and compiler specific/platform- and compiler-specific/
> .
> The following programs are included:
> * mpc-ace, generating project files for a single target
> * mwc-ace, generating workspace files for a set of projects
>
> Package: libace-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: C++ network programming framework
> This package contains the ADAPTIVE Communication Environment (ACE)
> framework.
(Thanks for explaining Why The Name... but what does "ADAPTIVE" itself
mean - is it an acronym?)
> .
> It provides platform independent C++ wrappers for interprocess
> communication:
> * signals
> * pipes
> * sockets
> * message queues
> * semaphores
> * shared memory
Isn't this just "for all forms of IPC"?
> as well as thread, process management routines and much more.
Is this missing an "and" ("thread- and process-management routines")
or is the comma meant as a slash ("thread/process management")?
> .
> Moreover, it defines patterns for common communication tasks. Beyond
> these:
> * Reactor, to handle event demultiplexing and dispatching
> * Proactor, for asynchronous I/O driven programs
Beyond them? What does that mean?
> Package: libace-dev
> Architecture: any
> Section: libdevel
> Depends: libace-6.0.1 (= ${binary:Version}), ${misc:Depends}
> Suggests: libace-doc, libtao-dev, pkg-config
> Replaces: mpc-ace (<< 5.6.3-4)
> Description: C++ network programming framework development files
> This package contains the header files and static library for the ACE
> framework.
>
> Package: libace-doc
> Architecture: all
> Section: doc
> Depends: ${misc:Depends}
> Suggests: libace-dev
> Recommends: doc-base
> Description: C++ network programming framework documentation
> This package contains the ACE overview documentation, tutorials,
> examples, and information regarding upstream development.
(Note that this list already has the "serial comma" punctuation style
I'm enforcing elsewhere.)
> Package: libace-ssl-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE secure socket layer library
> This package contains wrappers that integrate the OpenSSL library in
> the ACE framework.
>
> Package: libace-ssl-dev
> Architecture: any
> Section: libdevel
> Depends: libace-ssl-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), libssl-dev (>= 0.9.7d), ${misc:Depends}
> Description: ACE secure socket layer library development files
> This package contains the header files and static library for the ACE
> SSL library.
>
> Package: libace-rmcast-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE reliable multicast library
> The RMCast library is a reliable source-ordered multicast protocol
> implementation.
> .
> It uses sequence number for re-ordering, duplicate suppression and
> loss detection of messages.
Wobbly English; I would suggest rephrasing it along these lines:
It uses sequence numbers on messages to ensure ordering, loss
detection, and suppression of duplicates.
> Package: libace-rmcast-dev
> Architecture: any
> Section: libdevel
> Depends: libace-rmcast-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), ${misc:Depends}
> Description: ACE reliable multicast library development files
> This package contains the header files and static library for the ACE
> reliable multicast library.
>
> Package: libace-tmcast-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE transactional multicast library
> The TMCast library is a transaction multicast protocol
> implementation.
Missing -al on "transactional".
> .
> Each message is delivered to multicast group members as a
> transaction: an atomic, consistent and isolated action.
Add serial comma: "atomic, consistent, and isolated".
> Package: libace-tmcast-dev
> Architecture: any
> Section: libdevel
> Depends: libace-tmcast-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), ${misc:Depends}
> Description: ACE transactional multicast library development files
> This package contains the header files and static library for the ACE
> transactional multicast library.
>
> Package: libace-htbp-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE protocol over HTTP tunneling library
> The HTTP Tunneling, Bidirectional, Protocol (HTBP) library enables
> the writing of stream-based protocols over HTTP.
(The odd punctuation of HTBP doesn't achieve anything, but it seems to
be the official upstream rendering, so I'll leave it.)
> .
> This allows clients behind a firewall to establish a connection with
> outbound servers using the HTTP protocol.
>
> Package: libace-htbp-dev
> Architecture: any
> Section: libdevel
> Depends: libace-htbp-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), ${misc:Depends}
> Description: ACE protocol over HTTP tunneling library development files
> This package contains the header files and static library for the ACE
> HTBP library.
>
> Package: libace-inet-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE library for Inet protocol clients
If it's intended eventually to deal with servers, too, it might make
sense to take out the word "clients" (and reorganise slightly):
Description: ACE Inet protocol library
(This also makes libace-inet-ssl-dev's synopsis more manageable.)
> ACE addon library for Inet protocol clients (and possibly servers
> at some point) like http://, ftp:// etc
Is "Inet" the right term here (in short and long descriptions), or
would it be more accurate to say that it's a library for (using the
inet interface to) Internet protocol clients? For now I'll leave it
as it is, but there's also some very confused plumbing - it's a
library for clients that are "like" the File Transfer Protocol?
This package provides an ACE addon library for clients (and possibly
servers at some point) using Inet protocols, such as HTTP or FTP.
> Package: libace-inet-dev
> Architecture: any
> Section: libdevel
> Depends: libace-inet-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), ${misc:Depends}
> Description: ACE library for Inet protocol clients development files
> ACE addon library for Inet protocol clients (and possibly servers
> at some point) like http://, ftp:// etc
To follow the example of other packages this would be
Description: ACE Inet protocol library development files
This package contains the header files and static library for the ACE
Inet protocol library.
> Package: libace-inet-ssl-6.0.1
> Architecture: any
> Section: libs
> Depends: libace-inet-6.0.1, libace-ssl-6.0.1, ${shlibs:Depends},
> ${misc:Depends}
> Description: ACE library for Inet protocol clients with SSL support
> ACE addon library for Inet protocol clients (and possibly servers
> at some point) which support SSL like https://, ftps:// etc
Description: ACE SSL-enabled Inet protocol library
This package provides an ACE addon library for clients (and possibly
servers at some point) using Inet protocols which support SSL, such as
HTTPS or FTPS.
>
> Package: libace-inet-ssl-dev
> Architecture: any
> Section: libdevel
> Depends: libace-inet-ssl-6.0.1 (= ${binary:Version}), libace-inet-dev (=
> ${binary:Version}), libace-ssl-dev (= ${binary:Version}), ${misc:Depends}
> Description: ACE library for Inet protocol clients with SSL support development files
> ACE addon library for Inet protocol clients (and possibly servers
> at some point) which support SSL like https://, ftps:// etc
Description: ACE SSL-enabled Inet protocol library development files
This package contains the header files and static library for the ACE
SSL-enabled Inet protocol library.
> Package: ace-gperf
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Conflicts: gperf-ace (<< 5.7.7-1)
> Replaces: gperf-ace (<< 5.7.7-1)
> Description: ACE perfect hash function generator
> ace_gperf is the ACE version of gperf.
> .
> Both ace_gperf and gperf were written by the same author, and have
> basically the same options and functionality. ace_gperf simply takes
> advantage of the some of the features provided by the ACE library.
^^^
Excess article.
> Package: gperf-ace
> Architecture: all
> Depends: ace-gperf, ${misc:Depends}
> Description: ACE perfect hash function generator (transitional package)
> This package is a transitional package to ace-gperf.
> .
> It can be safely removed after installation.
>
> Package: libacexml-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE SAX based XML parsing library
> This package provides interfaces for XML parsing based on Simple API
> for XML (SAX) 2.0, defined by David Megginson. This is an
> event-driven parsing approach.
Probably a "useless use of based" (if it's following the Simple API
for XML, it's not just a SAX-based XML parsing library, it's an actual
SAX library!), but at least it breaks up the string of TLAs, so I'll
leave it.
> .
> ACEXML is a small footprint and portable library. It does not
> validate XML documents and supports only Unicode encoding.
Using "small footprint" as an adjective is a bit dodgy, but probably
not worth fixing.
> Package: libacexml-dev
> Architecture: any
> Section: libdevel
> Replaces: libace-dev (<< 5.7.7-4)
> Depends: libacexml-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), ${misc:Depends}
> Description: ACE SAX based XML parsing library development files
> This package contains the header files and static library for the ACE
> XML parsing library.
>
> Package: libkokyu-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Suggests: libtao-2.0.1, libtao-orbsvcs-2.0.1
> Description: ACE scheduling and dispatching library
> Kokyu is a library designed to provide flexible scheduling and
> dispatching services.
> .
> Currently it provides real-time scheduling and dispatching services
> for TAO real-time CORBA Event Service.
Is there a missing article in that last line? Or maybe it should be:
for TAO's real-time CORBA Event Service.
But similar phrasings crop up in lots of other places below, so I'll
leave them all for now.
> Package: libkokyu-dev
> Architecture: any
> Section: libdevel
> Depends: libkokyu-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), ${misc:Depends}
> Description: ACE scheduling and dispatching library development files
> This package contains the header files and static library for the ACE
> scheduling and dispatching library.
>
> Package: libace-qtreactor-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE-GUI reactor integration for Qt
> Recognizing the need to write reactor-based GUI applications, the ACE
> community has created several reactor extensions for use with X
> Window System. Each of these extends the ACE_Select_Reactor to work
> with a specific toolkit. By using these reactors, your GUI
> application can remain single threaded yet still respond to both GUI
> events, such as button presses, any your own application events.
Typo: s/any/and/ here and in other libace-*reactor-* packages.
> .
> The ACE_QtReactor extends both the ACE_Select_Reactor and the
> Trolltech Qt library's QObjects class. Rather then using select(),
> the QtWaitForMultipleEvents() function is used.
A one-off typo: s/then/than/
> Package: libace-qtreactor-dev
> Architecture: any
> Section: libdevel
> Depends: libace-qtreactor-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), libqt4-dev, ${misc:Depends}
> Description: ACE-GUI reactor integration for Qt development files
These reactor-dev synopses especially would benefit from being split:
Description: ACE-GUI reactor integration for Qt (development files)
or
Description: ACE-GUI reactor integration for Qt - development files
> This package contains header files and static library for the ACE-Qt
> reactor integration.
>
> Package: libace-xtreactor-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE-GUI reactor integration for Xt
> Recognizing the need to write reactor-based GUI applications, the ACE
> community has created several reactor extensions for use with X
> Window System. Each of these extends the ACE_Select_Reactor to work
> with a specific toolkit. By using these reactors, your GUI
> application can remain single threaded yet still respond to both GUI
> events, such as button presses, any your own application events.
This has the same typo, but different spacing after full stops!
Standardise on singlespace.
> .
> The ACE_XtReactor extends both the ACE_Select_Reactor and the X
> Toolkit library function XtWaitForMultipleEvents().
>
> Package: libace-xtreactor-dev
> Architecture: any
> Section: libdevel
> Depends: libace-xtreactor-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), libxt-dev (>= 4.3.0), ${misc:Depends}
> Description: ACE-GUI reactor integration for Xt development files
> This package contains header files and static library for the ACE-Xt
> reactor integration.
>
> Package: libace-tkreactor-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE-GUI reactor integration for Tk
> Recognizing the need to write reactor-based GUI applications, the ACE
> community has created several reactor extensions for use with X
> Window System. Each of these extends the ACE_Select_Reactor to work
> with a specific toolkit. By using these reactors, your GUI
> application can remain single threaded yet still respond to both GUI
> events, such as button presses, any your own application events.
Fix typo, standardise on singlespace.
> .
> The ACE_TkReactor provides reactor functionality around the popular
> Tcl/Tk library. The underlying Tcl/Tk method used is
> Tcl_DoOneEvent().
Standardise on singlespace.
> Package: libace-tkreactor-dev
> Architecture: any
> Section: libdevel
> Depends: libace-tkreactor-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), tk-dev (>= 8.5), ${misc:Depends}
> Description: ACE-GUI reactor integration for Tk development files
> This package contains header files and static library for the ACE-Tk
> reactor integration.
>
> Package: libace-flreactor-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE-GUI reactor integration for Fl
> Recognizing the need to write reactor-based GUI applications, the ACE
> community has created several reactor extensions for use with X
> Window System. Each of these extends the ACE_Select_Reactor to work
> with a specific toolkit. By using these reactors, your GUI
> application can remain single threaded yet still respond to both GUI
> events, such as button presses, any your own application events.
Fix typo, standardise on singlespace.
> .
> The ACE_FlReactor integrates with the FastLight toolkit's Fl::wait()
> method.
>
> Package: libace-flreactor-dev
> Architecture: any
> Section: libdevel
> Depends: libace-flreactor-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), libfltk1.1-dev (>= 1.1.4), ${misc:Depends}
> Description: ACE-GUI reactor integration for Fl development files
> This package contains header files and static library for the ACE-Fl
> reactor integration.
>
> Package: libace-foxreactor-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE-GUI reactor integration for FOX
> Recognizing the need to write reactor-based GUI applications, the ACE
> community has created several reactor extensions for use with X
> Window System. Each of these extends the ACE_Select_Reactor to work
> with a specific toolkit. By using these reactors, your GUI
> application can remain single threaded yet still respond to both GUI
> events, such as button presses, any your own application events.
We're back to just fixing the typo.
> .
> The ACE_FoxReactor integrates with the FOX toolkit.
>
> Package: libace-foxreactor-dev
> Architecture: any
> Section: libdevel
> Depends: libace-foxreactor-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), libfox-1.6-dev, ${misc:Depends}
> Description: ACE-GUI reactor integration for FOX development files
> This package contains header files and static library for the ACE-FOX
> reactor integration.
>
> Package: libtao-2.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE based CORBA ORB core libraries
> The ACE ORB (TAO) is an open-source Common Object Request Broker
> Architecture (CORBA) 2.x-compliant Object Request Broker (ORB). It
> supports real-time extensions.
> .
> This package contains TAO core libraries.
>
> Package: libtao-dev
> Architecture: any
> Section: libdevel
> Replaces: libtao-orbsvcs-dev (<< 5.7.7-4)
> Depends: libtao-2.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), ${misc:Depends}
> Suggests: libtao-doc, libtao-orbsvcs-dev
> Description: ACE based CORBA ORB core libraries development files
> This package contains the header files for TAO. Due to the size of
> the static libs (> 400MB) they have been left out.
Standardise on singlespace and avoid the question of whether it should
be "> 400" or ">400" by saying:
the static libraries (over 400MB) they have been left out.
(Likewise below.)
> Package: libtao-doc
> Architecture: all
> Section: doc
> Depends: libace-doc (= ${source:Version}), ${misc:Depends}
> Suggests: libtao-dev
> Recommends: doc-base
> Description: ACE based CORBA ORB core libraries documentation
> This package contains the TAO overview documentation, tutorials,
> examples, and information regarding upstream development.
>
> Package: libtao-orbsvcs-2.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: TAO CORBA services libraries
> This package contains libraries that are needed by many TAO programs.
>
> Package: libtao-orbsvcs-dev
> Architecture: any
> Section: libdevel
> Replaces: libtao-dev (<< 5.7.7-4)
> Depends: libtao-orbsvcs-2.0.1 (= ${binary:Version}), libtao-dev (=
> ${binary:Version}), ${misc:Depends}
> Description: TAO CORBA services development files
> This package contains the header files for the TAO CORBA services.
> .
> Due to the size of the static libs (> 400MB) they have been left out.
> The examples and some documentation have been included as well.
"As well" needs to follow on from something being included, not
excluded, so say it the other way around:
The examples and some documentation have been included as well, but the
static libraries have been left out due to their size (over 400MB).
>
> Package: libtao-qtresource-2.0.1
[...]
> Package: tao-idl
> Architecture: any
> Depends: libtao-2.0.1 (= ${binary:Version}), ${shlibs:Depends},
> ${misc:Depends}
> Description: TAO IDL to C++ compiler
> This package provides a Interface Definition Language (IDL) to C++
> compiler.
s/a Interface/an Interface/
> .
> Use tao_idl to generate stubs and skeletons to call or implement
> CORBA distributed objects in C++.
Must I?
> Package: tao-ifr
> Architecture: any
> Depends: libtao-2.0.1 (= ${binary:Version}), ${shlibs:Depends},
> ${misc:Depends}
> Description: TAO interface repository
> CORBA-aware programs can contact an interface repository to get
> objects interfaces at run-time. Then they can use the Dynamic
> Invocation Interface (DII) mechanism to invoke requests on those
> objects.
Should that be "objects' interfaces" with possessive-plural
apostrophe?
> .
> This package includes the following programs:
> * IFR_Service: interface repository server
> * tao_ifr: feeds in the interface repository
What does "feeds in" mean there? Does something feed something into
the interface repository (or maybe feed itself within the interface
repository), or does tao_ifr provide feeds, or what?
> Package: tao-imr
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: TAO implementation repository
> An implementation repository activates CORBA servers on demand.
> .
> This package includes the following programs:
> * ImplRepo_Service: the main server; delegates call to activators
> * ImR_Activator: activates and shuts servers down on demand
> * tao_imr: registers servers for later activation
Should that be "delegates calls" (as in, ImplRepo_Service is a program
that delegates calls)?
> Package: tao-ft
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: TAO fault tolerant services
> TAO supports Fault Tolerance for CORBA Objects.
> .
> This package includes three FT CORBA infrastructure components:
> * Fault_Detector that monitors a process or a host
> * Fault_Notifier that receives fault reports from detectors
> * FT_ReplicationManager that manages object groups
These uses of "that" are awkward; standardise it to:
* Fault_Detector: monitors a process or a host
* Fault_Notifier: receives fault reports from detectors
* FT_ReplicationManager: manages object groups
> Package: tao-utils
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Suggests: tao-cosnaming
> Description: TAO naming service and IOR utilities
> This package includes programs to query or control a CORBA naming
> service, and to dump an IOR.
> .
> The following programs are included:
> * tao_nslist, to list naming context and object bindings
> * tao_nsadd, to create bindings
> * tao_nsdel, to remove bindings
> * tao_catior, to dump the content of an Interoperable Object Reference
Expand IOR in the intro paragraph, not the last line:
Description: TAO naming service and IOR utilities
This package includes programs to query or control a CORBA naming
service, and to dump an Interoperable Object Reference.
.
The following programs are included:
* tao_nslist: lists naming context and object bindings
* tao_nsadd: creates bindings
* tao_nsdel: removes bindings
* tao_catior: dumps the contents of an IOR
>
> Package: tao-cosnaming
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Conflicts: tao-naming (<< 5.7.7-1)
> Replaces: tao-naming (<< 5.7.7-1)
> Recommends: tao-utils
> Description: TAO naming service
> TAO implementation of CORBA interoperable naming service (INS).
Not a sentence. Maybe:
The TAO naming service implements the CORBA interoperable naming
service (INS).
> .
> A naming service provides a location service for CORBA objects.
> Given a name, it will return the Interoperable Object Reference (IOR)
> for the CORBA object that was registered with this name.
> .
> The following program is included:
> * tao_cosnaming
(We get no explanation for the COS = "CORBA Object Service" in all
these packagenames, but I can't see how to add one without it being
painfully repetitive.)
> Package: tao-naming
> Architecture: all
> Depends: tao-cosnaming, ${misc:Depends}
> Description: TAO naming service (transitional package)
> This package is a transitional package to tao-cosnaming.
> .
> It can be safely removed after installation.
>
> Package: tao-costrading
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Conflicts: tao-trading (<< 5.7.7-1)
> Replaces: tao-trading (<< 5.7.7-1)
> Description: TAO trading service
> TAO implementation of CORBA trading service.
> .
> A trading service is quite like a naming service except that it
> relies on a set of properties instead of a name to find object
> references.
> .
> The following program is included:
> * tao_costrading
>
> Package: tao-trading
> Architecture: all
> Depends: tao-costrading, ${misc:Depends}
> Description: TAO trading service (transitional package)
> This package is a transitional package to tao-costrading.
> .
> It can be safely removed after installation.
>
> Package: tao-cosevent
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Conflicts: tao-event (<< 5.7.7-1)
> Replaces: tao-event (<< 5.7.7-1)
> Description: TAO event service
> An event service creates channels where suppliers and consumers can
> push or pull events. This channel enables asynchronous, message based
> communication between consumers and suppliers.
> .
> This event service supports both the Push and Pull styles for event
> communication.
> .
> The following program is included:
> * tao_cosevent
The phrase "message based communication" puzzles me (can you have
communication without a message?), but maybe I'm happier not knowing
why it says this.
>
> Package: tao-event
> Architecture: all
> Depends: tao-cosevent, ${misc:Depends}
> Description: TAO event service (transitional package)
> This package is a transitional package to tao-cosevent.
> .
> It can be safely removed after installation.
>
> Package: tao-rtevent
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: TAO real-time event service
> Another TAO implementation of CORBA event service. For more
> information on CORBA event service have a look at tao-cosevent
> package.
> .
> This version does not support the Pull style but provides a real-time
> event channel.
> .
> The following program is included:
> * tao_rtevent
Insert "This package provides". There's at least one definite article
missing in that first paragraph.
> Package: tao-ftrtevent
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: TAO fault-tolerant real-time event service
> TAO fault-tolerant, real-time CORBA event service. For more
> information on CORBA event service have a look at tao-cosevent
> package.
Ditto.
> .
> This package contains:
> * ftrt_eventservice, the fault-tolerant event channel
> * ftrtec_factory_service, spawning ftrt_eventservice processes
> * ftrtec_gateway_service, relaying events to FT CORBA unaware clients
Stylistic homogenisation:
* ftrt_eventservice: fault-tolerant event channel
* ftrtec_factory_service: spawns ftrt_eventservice processes
* ftrtec_gateway_service: relays events to FT CORBA unaware clients
> Package: tao-cosnotification
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Conflicts: tao-notify (<< 5.7.7-1)
> Replaces: tao-notify (<< 5.7.7-1)
> Description: TAO notification service
> A notification service enhances an event service. For more
> information on CORBA event service have a look at tao-cosevent
> package.
> .
> The notification service adds:
> * quality of service control on reliability and speed
> * event filtering
That didn't need to be a bulleted list. Just say:
A notification service enhances an event service, providing event
filtering and Quality Of Service control on reliability and speed.
For more information on CORBA event service have a look at the
tao-cosevent package.
> .
> This package contains:
> * tao_cosnotification
>
> Package: tao-notify
> Architecture: all
> Depends: tao-cosnotification, ${misc:Depends}
> Description: TAO notification service (transitional package)
> This package is a transitional package to tao-cosnotification.
> .
> It can be safely removed after installation.
>
> Package: tao-load
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: TAO load balancing service
> TAO implementation of OMG Load Balancing and Monitoring
> specification.
> .
> This package provides:
> * LoadManager, that distributes loads across objects
> * LoadMonitor, that monitors and reports loads to a manager
>
The TAO load balancer implements the OMG Load Balancing and
Monitoring specification.
.
This package provides:
* LoadManager: distributes loads across objects
* LoadMonitor: monitors and reports loads to a manager
> Package: tao-tls
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Conflicts: tao-log (<< 5.7.7-1)
> Replaces: tao-log (<< 5.7.7-1)
> Description: TAO telecom log services
Oh, that TLS!
> TAO implementations of CORBA telecom log service.
This should be a sentence. Is there some appropriate term like
"module" that we could use to form descriptions along the following
lines?
The TAO TLS module implements CORBA telecom log services.
Or more usefully it could explain what Telecom Log Services are.
Would something like this be accurate?
Telecom log services provide a channel for propagating log events.
(The same applies to various other packages in this group.)
> .
> Four separate services are provided:
> * tao_tls_basic
> * tao_tls_event
> * tao_tls_notify
> * tao_tls_rtevent
>
> Package: tao-log
> Architecture: all
> Depends: tao-tls, ${misc:Depends}
> Description: TAO telecom log services (transitional package)
> This package is a transitional package to tao-tls.
> .
> It can be safely removed after installation.
>
> Package: tao-scheduling
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: TAO scheduling service
> TAO implementation of CORBA scheduling service.
Again this needs to be a sentence; either:
The TAO scheduling module implements CORBA scheduling services.
or maybe:
Scheduling services allow CORBA objects to organise picnics.
(or whatever it is they do)
> .
> This package contains:
> * Scheduling_Service
> * Dump_Schedule
>
> Package: tao-cosconcurrency
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Conflicts: tao-concurrency (<< 5.7.7-1)
> Replaces: tao-concurrency (<< 5.7.7-1)
> Description: TAO concurrency service
> A concurrency service provides a mechanism to acquire and release
> locks in a distributed system.
> .
> TAO version does not support transactions.
Insert article, or make it "TAO's".
>
> Package: tao-concurrency
> Architecture: all
> Depends: tao-cosconcurrency, ${misc:Depends}
> Description: TAO concurrency service (transitional package)
> This package is a transitional package to tao-cosconcurrency.
> .
> It can be safely removed after installation.
>
> Package: tao-coslifecycle
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Conflicts: tao-lifecycle (<< 5.7.7-1)
> Replaces: tao-lifecycle (<< 5.7.7-1)
> Description: TAO lifecycle service
> The CORBA lifecycle service allows clients to create, delete, copy
> and move objects.
Insert serial comma.
> .
> This package contains the TAO implementation of such service.
Such *a* service, but just say "contains a TAO implementation."
>
> Package: tao-lifecycle
> Architecture: all
> Depends: tao-coslifecycle, ${misc:Depends}
> Description: TAO lifecycle service (transitional package)
> This package is a transitional package to tao-coslifecycle.
> .
> It can be safely removed after installation.
>
> Package: tao-costime
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Conflicts: tao-time (<< 5.7.7-1)
> Replaces: tao-time (<< 5.7.7-1)
> Description: TAO time service
> A time service offers globally synchronized time to clients.
> .
> This package contains two programs:
> * tao_costime_clerk, answering client requests
> * tao_costime_server, queried by clerks to keep their time
> synchronized
Maybe:
* tao_costime_clerk: answers client requests
* tao_costime_server: synchronizes querying clerks
> Package: tao-time
> Architecture: all
> Depends: tao-costime, ${misc:Depends}
> Description: TAO time service (transitional package)
> This package is a transitional package to tao-costime.
> .
> It can be safely removed after installation.
>
> Package: ace-netsvcs
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE network service implementations
> ACE network services provide reusable components for common
> distributed system tasks such as logging, naming, locking, and time
> synchronization.
> .
> This package contains driver program and exemplary configuration
> files that links the various ACE network services together, either
> statically or dynamically, to form complete server programs.
Grammar problems, but I think it's trying to say:
This package contains driver programs and example configuration
files to link the various ACE network services together, either
statically or dynamically, and form complete server programs.
> Package: libnetsvcs-6.0.1
> Architecture: any
> Section: libs
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Description: ACE network service implementations
> ACE network services provide reusable components for common
> distributed system tasks such as logging, naming, locking, and time
> synchronization.
> .
> This package contains runtime libraries for ACE network services.
>
> Package: libnetsvcs-dev
> Architecture: any
> Section: libdevel
> Depends: libnetsvcs-6.0.1 (= ${binary:Version}), libace-dev (=
> ${binary:Version}), ${misc:Depends}
> Description: ACE network service implementations
> ACE network services provide reusable components for common
> distributed system tasks such as logging, naming, locking, and time
> synchronization.
> .
> This package contains header files and static library for the ACE
> network services library.
These last ones are okay apart from the undifferentiated synopses:
Description: ACE network service implementations
Description: ACE network service implementations (libraries)
Description: ACE network service implementations (development files)
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
More information about the Pkg-ace-devel
mailing list