Splitting up cygwin packages

[Christopher Faylor]

I'll probably regret mentioning this because it is a potential bikeshed
issue but, here goes:

I suggested to Corinna that it would be nice to break up the cygwin package
into four different packages:

- cygwin Category: base

containing the dll

- cygwin-devel Category: devel

containing headers and import libraries

- cygwin-server Category: base(?)

containing cygserver and cyglsa

- cygwin-utils Category: base

containing the content of winsup/utils

The versioning for all of the above would reflect the dll version.

There are two motivations here:

1) Allow updating non-dll packages for important bug fixes which
do not require a dll version bump (like the recent cygcheck bug).
This would be a rare occurrence but it means that there could be,
e.g., a cygwin-utils-1.7.27-2 package. The utilities would report
"1.7.27" while "cygcheck -c cygwin-utils" would report 1.7.27-2.

2) Allow decoupling the development files from a normal installation
for people who don't need the headers/libraries.

The change would mean that all devel packages would need to rely
on cygwin-devel. I'm willing to make that automatic in upset.

Packages which rely on the cygwin utils would obviously need to
require: cygwin-utils, although since cygwin-utils is in the base
category, it won't be a big issue.

We're tentatively thinking about starting this in 1.7.27.

Am I missing anything else? Does cygwin-server belong in the base
category?

cgf

[Corinna Vinschen]

Post by Christopher Faylor
I'll probably regret mentioning this because it is a potential bikeshed
I suggested to Corinna that it would be nice to break up the cygwin package
- cygwin Category: base
containing the dll
- cygwin-devel Category: devel
containing headers and import libraries
- cygwin-server Category: base(?)
containing cygserver and cyglsa
- cygwin-utils Category: base
containing the content of winsup/utils
The versioning for all of the above would reflect the dll version.
1) Allow updating non-dll packages for important bug fixes which
do not require a dll version bump (like the recent cygcheck bug).
This would be a rare occurrence but it means that there could be,
e.g., a cygwin-utils-1.7.27-2 package. The utilities would report
"1.7.27" while "cygcheck -c cygwin-utils" would report 1.7.27-2.

On second thought, I don't think this is feasible. It's not done on
rpm-based systems either. You're building all subpackages from a single
rpm spec file at once, and they are all uploaded together. Even if only
a header changed in glibc-devel, the update will consist of all glibc
packages (and there are a couple of them) bumped to the new release.
The same holds true for cygport. If I build all -2 or -3 packages in
one go anyway, I can upload all of them easily.

Post by Christopher Faylor
2) Allow decoupling the development files from a normal installation
for people who don't need the headers/libraries.
The change would mean that all devel packages would need to rely
on cygwin-devel. I'm willing to make that automatic in upset.
Packages which rely on the cygwin utils would obviously need to
require: cygwin-utils, although since cygwin-utils is in the base
category, it won't be a big issue.
We're tentatively thinking about starting this in 1.7.27.

On third thought I would rather opt for two packages only.
cygwin with everything in /usr/bin and /usr/sbin, except dumper
and ssp., cygwin-devel with dumper, ssp, headers and libs.

Post by Christopher Faylor
Am I missing anything else? Does cygwin-server belong in the base
category?

Yes. No XSI IPC without cygserver.


Corinna

[Christopher Faylor]

Ok. Nevermind. Idea withdrawn.

cgf