Re: noarching source packages

[Achim Gratz <Stromeko at nexgo dot de>]

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.

> 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.

>> 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.

>> The only sane way is to mandate that the packages for all arches are
>> built together so that you can package the sources only once during the
>> packaging step.  Otherwise you either have to check that the contents
>
> That would seem to require a cross-compilation environment for at
> least one cygwin arch, with all the dependencies available.

Not necessarily.  You just need to package both with the same step.  But
yes, cygport makes this perhaps a bit harder than it should.

>> It's easy enough to branch that decision inside the cygport file and the
>> only time I did that have passed now that the package content in both
>> arches is almost identical.  So is anybody really doing that currently?
>
> At the moment, nothing prevents SRC_URI and PATCH_URI depending on the
> ARCH, so we just don't know.
>
> But this is more a question of workflow: nothing stops the maintainer
> going back and changing the source package, then just rebuilding one
> architecture.

So just define some variable in *.cygport that says "I'm not doing any
of that nonsense and want to build for two arches".  Unless it's set,
everything stays as it is today.

> The ideal solution would be a build service which accepts a source
> package and produces the install archives, but I don't see that
> happening anytime soon...

Me neither.

>> But the real problem is that besides our own stuff some upstream sources
>> are archful.
>
> Examples?

Last I looked, it was texlive.  No idea why.

>> The way it would work is that setup.exe should accept both noarch and
>> arch archives for the same package.  It would then proceed to first
>> install the noarch and then the arch part if it finds both of them.
>> Incidentally, this would keep the current tree structure intact and
>> allow us to freely move packages from arch to noarch and vice versa
>> between different releases with no manual intervention.
>
> Great.  I look forward to reading the patches :)

You're talking about setup.exe, calm or both?  I'm tied up at work
for the foreseeable future, so I can't spend many cycles on it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada