Re: noarching source packages

[Jon Turney <jon.turney@dronecode.org.uk>]

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
> purpose.  So
>
> package-version-release[-purpose].tar.xz
>
> 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.
>
> Agreed.
>
>>> 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)?