Mail Archives: cygwin-apps/2001/11/14/17:33:45
----- Original Message -----
From: "Stipe Tolj" <tolj AT wapme-systems DOT de>
> Robert,
>
>
> who is going to advice the package maintainers to check for these file
> conflicts?!
Well if we can lint the packages at upload time, I guess Chris will get
the failure message (Chris, I'm happy to be copied on that if you want).
Otherwise, I think you(Stipe)'ll have to do it for now.
> >
> > I'm not sure what you mean here, can you explain further?
>
> The script I wrote may check file conflicts based upon package
> dependancies, i.e. the require field of setup.ini and setup.hint. By
> that way we may distinguiss which file conflicts are "less" paranoid
> (if the corresponding packages are dependable) or "more" paranoid (if
> they are loosely or none related).
>
> It would only proclaim which file conflicts seem to be very easily
> resolveable and which ones are related because of package dependance.
Do you mean that if one package is dependent on another, you will
announce the conflict, and if they are not you won't?
I think this logic is wrong. We need a conflicts-with entry for
setup.hint, but there areother things I think we need first.
> > This is wrong. It's up to the package maintainer to choose .tar.gz
or
> > .tar.bz2, and if the package is going to be changed the cygwin
version
> > suffix MUST be bumped.
>
> is this defined such a way in /setup.html?! I would suggest .bz2
> because of compression performance.
Yes, sort of, see "package naming". I don't see that we need to enforce
one or other compression format right now.
> The main problem is defined as follows: how much control should/must
> the package maintainer
Absolute control subject to...
> have and how much post-ante abilities should
> the Cygwin projects (as general subject) have to prune or normalize
> the packages, like the decission to use .bz2 instead of gzip?!
...meeting the Cygwin project policy. Which is currently rather
informal, and this list acts as the discussion group for it. I.e.
overwriting info.dir is against the policy. Not handling textmode issues
is... against the policy.
The problem with an automated tool making _any_ change to a package is
that it is automated, not wetware.
> The best way would be to proclaim rules. I suppose /setup.html does
> this in general, so it is up to the maintainer here?
/setup.html was (mostly) created by writing down the already existing
rules discussed and formalised in this forum. As new ones are created
and agreed to setup.html will include them.
Rob
- Raw text -