This is the mail archive of the
mailing list for the Cygwin project.
Re: noarching source packages
- From: Jon Turney <jon dot turney at dronecode dot org dot uk>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 4 May 2017 20:42:25 +0100
- Subject: Re: noarching source packages
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <87wpa54u0a.fsf@Rainer.invalid> <firstname.lastname@example.org> <87lgqg73kr.fsf@Rainer.invalid>
On 01/05/2017 20:57, Achim Gratz wrote:
Jon Turney writes:
What is your reason for changing the name?
There shouldn't be two different naming conventions for the same
with purpose:=[source|debuginfo] would be preferrable.
If we were starting from scratch, maybe.
The assumption that the "package" part is unique for installable
packages is rather deeply entrenched, and I don't actually see any
benefit apart from the aesthetic in changing this now.
If we're going for a foolish consistency, naming things as
package-version[-purpose]-release would be probably easier to implement :-)
I was wondering if we need to explicitly identify debuginfo archives
as a different kind of thing. Currently, debuginfo packages work just
like any other install archive, which is fine, except for perhaps they
need a separate filter in setup.
They wouldn't with the above naming convention and you'd just tick
another box to say you want them installed, just like sources. We might
even skip the archful directories and just do [noarch|x86|x86_64] as
well in the same place.
I think it would be much better to have the associated debuginfo for a
package described in setup.ini, rather than mapping package name ->
source package name -> debuginfo package name, as you seem to be suggesting.
part of them is made up again of the source files, which should be
separated out into noarch also.
Nice idea, but the practicalities seem complex (e.g. generated source
files needs to be treated correctly). In any case, this would seem to
be a piece of work which falls after noarching the sources.
I'd be hesitant to use yet another tree for this. We already have way
too many directories that make up the repo.
'too many'? why?
I currently have to pull the mirror through a HTTP proxy, and most of
the time is spent in traversing directories. Yes, it'd be possible to
determine which packages are missing and directly pull those, but I
haven't got around to scripting that yet.
Ah, "too many" in some specific and limited sense. :-)
I'm not sure how many people are the situation of "I want to maintain a
mirror, but can't use rsync".
It seems a reasonable intuition that a more compact directory tree would
be somewhat more efficient, but that is basically saying that the
connection setup time for transferring index.html dominates.
Have you tried a HTTP mirroring tool which can parallelize it's requests
(assuming such a thing exists, I think axel can do that)?