On Tue, 14 Jul 2009 13:58 +0100, "Keith Marshall" wrote:
> On Tuesday 14 July 2009 01:47:51 Charles Wilson wrote:
> > >> 3. About FRS "Package" and "Release" naming. If the package
> > >> name includes 'MinGW', then must each Release also do so?
> > >> Currently, I have as an example:
> > >> Package: MinGW Utilities - bzip2
> > >> Release: bzip2-1.0.5-1-mingw32 <<<< seems a little
> > >> redundant File(s): ...
> > >
> > > Except that mingw-get will never see the package group name, as
> > > assigned to the virtual package name in FRS; (nor will that be
> > > seen by users who simply list the files on any mirror site).
> > But it won't see the "Release" name either, will it?
> > Just...files.
> That's true; I was confusing the "Release" name with actual file
> names. However, what if we have
> Package: MinGW Utilities: foo
> Release: foo-1.2.3-1-mingw32
> Files: ...
> Release: foo-1.2.3-1-mingw64
> Files: ...
> or, are you advocating that mingw32 and mingw64 files should be
> intermingled within a single "Release" container?
No - I guess not. I try to remember it, but I keep forgetting about
mingw64 since we don't actually have any of those yet.
It doesn't really make sense to repeat the "subsystem" twice. How about
1) if we named the Packages simply "foo":
Release: foo-1.2.3-1-mingw32 (subsys in Release)
Files: ... (and repeated in [most of] the files)
2) or, explicitly mention the subsystem name in the Package, not the
Package: MinGW foo (or MinGW-32, mingw32, or 'MinGW foo 32bit')
Release: foo-1.2.3-1 (no subsys here)
Files: ... (but most of the files have it)
Package: MinGW-64 foo (or some variation)
Release: foo-1.2.3-1 <<< note: same as above
Package: MSYS foo
I like #2, myself -- but I'm not sure if the FRS allows you to have two
different "Releases" of exactly the same name, even if they belong to
different "Packages". I think it does...
Also, I like omitting "Utilities" or "Library" from the package name.
What is gettext, anyway? A collection of utilities, or the libintl
> Yes. My current experimental mingw-get uses a monolithic XML
> database to describe all available packages, their affiliations to
> named package groups, and their inter-dependencies in terms of
> per-package "requires" elements. Ultimately, I expect to provide
> tools, to construct the database from per-package XML fragments.
Right, that's what I remember.
> > For direct downloaders...we can't help that. Not unless we move
> > the dlhost to something we can actually control.
> No. SF is a lost cause. Earnie and I are already exploring the
> possibilities for hosting on mingw.org
Oh, that would be SO excellent. sftp/ssh access for contributors, and
I'd be over the moon.
> > (1) A *true* mingwPORT, because it has no binaries, needs no
> > source. It just "is". Which brings up another point: mingwPORTs
> > need no 'Component Type' field...
> Except that pkginfo.l gets horribly confused, if the Component Type
> isn't specified. Thus, if we ever anticipate using mingw-get to
> deliver mingwPORTs, a Component Type would need to be specified;
> since all mingwPORTs are a collection of shell scripts, perhaps we
> could adopt sh as their Component Type.
Hmmm. Or "script"? Nah, too long. "scr" -- nah, too inscrutable, and
looks like a typo for "src". Ok, having thought about it for 12.3
seconds, I could go along with 'sh', as in
> > it
> > kinda makes a lie of my statement about "don't use hyphens here,
> > or <bad things>"...
> Where you've said it, it think it is true.
> By the very nature of a
> flex scanner, and by virtue of its look-ahead operation, it's what
> comes *after* the (hyphen) delimiter that determines its actual
> disposition. In general, it is true to say that, in pkginfo.l's
> grammar, the hyphen serves as a field separator; it is just in the
> specific cases of Package Name and Subsystem Name, multiple
> consecutive alphanumeric fields, until a following purely numeric,
> or dotted numeric field is detected, are re-assembled into a single
> logical field. Similarly, in the specific cases of the Package
> Build and the Subsystem Build, multiple consecutive purely numeric
> fields, (but excluding dotted numeric fields), until a following
> field is *not* purely numeric, are re-assembled.
So, hyphens can be a field separator. But not all hyphens are field
The same is true of periods: some are (.tar.lzma), but some are not
Conclusion: all field separators are either '-' or '.' -- but not all
[-.] are field separators.
> As a final note on this, the Component Type is identified as an
> alphanumeric field, with zero or one following purely numeric
> fields, and immediately followed by exactly one or two dotted
> extensions, which *must* lie at the rightmost extremity of the
> scanned file name.
Uhh...yeah. What he said.
> > I strongly disagree here.
> Then we have a philosophical difference of opinion, for which we need
> to find a compromise solution on which we can *all* agree.
> Fundamentally, I think it is wrong to distribute *any* package
> without also including appropriate licensing terms; if that isn't
> within *every* component package itself, then it *must* be in one
> specific component package within the set. In that case, it must be
> consistently in the *same* component package set of *every* package
> set we distribute. It could be the "doc" component, or it could be
> a "licence" component reserved explicitly for this purpose.
I'll yield on the larger point, but I disagree with your moral position:
I don't think that the only morally right choice is to include
distribution terms as an intrinsic element of every individual download
particle. If the location of the appropriate licensing terms is
reasonably obvious by name, proximity, or explicit policy, then it is
also morally correct to allow users the freedom to download only the
particles they want, without bundled licensing terms -- so long as they
are equally free to easily download also the particle that contains
> Whatever we choose, we need an explicit declaration, in the document
> currently under discussion, that the licensing terms for any package
> can be found in the component package of the chosen type, bearing
> the same package name, and we *must* provide a component of this
> chosen type, WITHOUT FAIL, for *every* package set we distribute.
Would (1) "if there is only one non-"-src" package for a given product,
then that package shall contain the appropriate license and
redistribution terms; otherwise, the license text shall appear in a
separate package with the "-license" Component Type" be okay?
I think either the above statement, or the following:
(2) Thou shalt always create a "-license" package that contains
share/doc/<PACKAGE>[-<VERSION>]/[aaaaa], where [aaaaa] represents one or
more files sufficient to convey all of the licensing and redistribution
terms appropriate for the <PACKAGE>-<VERSION> packageset. The -license
package should NOT contain additional, non-license-related
would be a reasonable compromise between your original "every tarball
shall have (possibly duplicate) license stuff" and my more liberal
"exactly one non-"-src" (sub)package shall contain the license stuff --
but you get to guess which one".
[*] Don't want to say share/doc/*/LICENSE because it might be
share/doc/*/COPYING -- or you might need more than one license file for
dual or multi licensed stuff.
The upside for (2) is that, for the mingw-get solution, EVERY
(sub)package in the packageset could require the -license subpackage,
perhaps even automatically.
One other question, and this holds for...well, all of the alternatives
discussed so far: what about the cross-build scripts? or mingwPORTS?
They are scripts, so are human readable, and contain their license text
directly. Must they, also, follow these rules (cut-n-paste that license
text into a separate file, package it into a matching -license package,
(err..maybe the cross-build scripts already have a separate LICENSE
file; not sure. And mingwPORTs usually contain a .README that also has
the license terms, so...)
> > This makes the life of any package
> > management system hell. If both package A and B contain
> > mingw/share/doc/foo/LICENSE
> > what do you do when the user uninstalls B? Do we need to keep
> > reference counts for all installed files, and only *really* remove
> > them when the last package referencing it is uninstalled?
> Actually, that's exactly what I was planning to do, with mingw-get.
Urk. For ALL files, or just the ones you know might be duplicated? How
do you know?
> > What if
> > the new version of B has an updated README, but the user keeps the
> > old version of A?
> Interesting concept; the user chooses to keep two components of the
> *same* package set, at *different* release points? That's a pretty
> good way to have things break in interesting and unpredictable ways.
Well, I was thinking about DLLs. IF the doc path was unversioned:
Most linux installations (and cygwin-1.7) seem to have moved away from
putting version numbers in the doc/foo-*/ pathnames. But we could avoid
this issue by requiring them. Probably, we NEED to require them, for
precisely this reason, even if we use one of my two alternative
> > You're deliberatly introducing "conflicts" -- which, in a normal
> > package management system, means that the metadata should indicate
> > that only one or the other of the conflicting packages should be
> > installed simultaneously. But, in this case, these conflicts are
> > introduced between packages that are inherently supposed to be
> > installed together: foo-bin, foo-dll, foo-dev, etc.
> Exactly. So *identically* the same licensing terms should apply to
> all, and all should be upgraded as a unit. You are imagining a
> conflict, where there really should not be one.
I was speaking about "conflicts" in a semantically-neutral way: two
files with the same pathname from two different packages == installer
sez, this is a conflict. (Or, without reference counting, you can
"break" package A by uninstalling package B, in the sense that the
filesystem no longer contains what the manifest for A says that it
If you add semantic awareness (e.g. *THIS* "conflict" is between files
that really OUGHT to appear in multiple simultaneously-installed
packages, because it contains license info) -- well, then you really do
need reference counting to make that work correctly.
I just wonder if adding semantic awareness and reference counting (or
even just reference counting alone, for ALL files, in a
semantically-agnostic manner) makes the installer "too smart for its own
good". I mean, installing and uninstalling files should be a pretty
simple task, no? [++] Adding complications just makes more stuff that
can break in unforeseen situations.
[++] I know, I know.
> Sure, you may have
> the wrong version of a licence installed, but that's not likely to
> actually break anything; the effect would be no different from the
> case where the user upgrades foo-*-bin, but leaves foo-*-doc at a
> former release point, (if it is foo-*-doc exclusively, which
> delivers the licence files).
> Indeed, it should be preferred that
> the upgrade to foo-*-bin should also upgrade the installed licence,
> because the more recent licence should, in most cases, reasonably be
> expected to be retrospectively applicable to the earlier release,
> while the converse may not be true.
So, going with option (2) above, AND -- for the mingw-get case, anyway
-- ensuring that all (sub)packages of a given packageset always require
the -license subpackage (as enforced in the xml), addresses both
One thing: the -license package should be a *package* -- e.g.
rather than simply a file
foo-1.2.3-1-mingw32-license.txt whose contents are the same as the
contents of the original COPYING file.
because in the latter case, (a) we have to work harder by renaming
files, (b) what if there are two or more licenses, and (3) mingw-get
doesn't know where to put it (unless we build policy into the software,
which is bad).
> > I know of NO linux distribution that does anything like this --
> > and there's a reason: it's a really bad idea. If somebody wants
> > the documentation, and doesn't already have it -- downloading the
> > associated "doc" package seems like a no-brainer to me.
> Just because you know of no Linux distro which does it, this doesn't
> necessarily make it a bad idea. It has its pros, and its cons, just
> as any other idea has. We have to choose the solution which seems
> most appropriate for us.
Well, recognizing the value of others' prior experience -- and their
rafts of lawyers -- is a virtue. IOW, if Red Hat's lawyers see no
(a) putting the COPYING file only in the -doc subpackage, or
(b) as long as it is present in SOME subpackage then sometimes putting
it in -doc and sometimes in (their equivalent of) -bin, then
we can probably assume there is no pressing LEGAL [**] reason for us to
impose more stringent requirements on ourselves.
[**] also recognizing that legal and moral are not synonyms
Because our clientele is different than Red Hat's, we may have other
rationales for imposing additional requirements of course; technical,