From: Jon Turney <jon.turney@dronecode.org.uk>
To: cygwin-apps@cygwin.com
Subject: noarching source packages
Date: Mon, 24 Apr 2017 13:04:00 -0000 [thread overview]
Message-ID: <de3fe890-42a5-ed5f-b1b7-3ad6ba03b5e2@dronecode.org.uk> (raw)
Picking up the discussion from [1], I've been looking a bit at noarching
the source packages.
So, the first problem is that we don't really have source packages.
Instead there is a special package (conventionally, the main one) which
has a source archive as well as a binary archive, and all the
subpackages point to that package with an external-source: hint, which
becomes a source: line pointing to that source archive in setup.ini.
(i.e. in that case, the setup.ini contains multiple, identical source:
lines for each subpackage)
* setup
Surprisingly, there is support in setup for source packages (See Source:
vs. source: in [2]), and this seems to work.
Note that the name of the source package must be distinct from the
binary package, so this probably implies some naming convention for
source packages (e.g. the source package for foo is foo-src)
(These foo-src packages currently will be shown in the list of packages.
This differs from current packages which are source-only, as these
aren't listed in setup.ini at all, and thus never shown in the list of
packages [this is was what skip: used to indicate, but these cases are
automatically detected, these days])
So, perhaps a minor improvement to setup to remove all packages which
are source-only from the displayed package list is needed, or to add a
separate filter view which only shows source packages?
(Note that source archives are already treated specially in other ways,
e.g. the files are just dumped in /usr/src/ and the package is not
recorded as being installed)
* calm
calm would need updating to look for packages in src/ as well as noarch/
and <arch>/, and to emit 'Source:' rather than 'source:' lines in
setup.ini when the source is an actual source package.
* cygport
It's not quite clear how to deal with making source packages. If we do
it when we make the binary package (as now), then there is the near
certainly that the source package made for a different arch will differ,
gratuitously.
(This will always be the case if gpg signing is turned on, as the .sig
inside the source archive is timestamped. It will also be the case if
timestamps or filesystem file order are leaked into the archive)
This will lead to a rejected upload (as uploading the same package with
different contents is not allowed by calm)
It's possible to make a separate step to make just the source package,
but perhaps this makes more work, as the maintainer will need to
explicitly do that (once), otherwise the upload will be rejected due to
not having a source.
This also potentially loses information, as the maintainer might adjust
the .cygport to build on the 2nd architecture they try, but those
changes wouldn't be uploaded, (whereas currently the source actually
used for the build is uploaded)
The source package will now always require a separate .hint, so we need
a means to manually provide a .hint file for that.
Uploading needs to place the source package in the appropriate place.
* benefit
Applied retroactively, it looks like this would save about 13G (out of a
total mirror size of approximately 97G), but it seems that there are
many source packages which (usually spuriously) differ between arches,
so that saving wouldn't be immediately realized.
> sware[...ftp/pub/cygwin]$ find x86 -name \*-src\* -print0 | du --files0-from=- -hc | tail -n1
> 13G total
> sware[...ftp/pub/cygwin]$ find x86_64 -name \*-src\* -print0 | du --files0-from=- -hc | tail -n1
> 13G total
[1] https://cygwin.com/ml/cygwin-apps/2016-04/msg00039.html
[2] https://sourceware.org/cygwin-apps/setup.ini.html
next reply other threads:[~2017-04-24 13:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-24 13:04 Jon Turney [this message]
2017-04-27 17:53 ` Achim Gratz
2017-05-01 19:35 ` Jon Turney
2017-05-01 19:57 ` Achim Gratz
2017-05-01 20:05 ` Ken Brown
2017-05-03 11:49 ` Ken Brown
2017-05-04 19:41 ` Jon Turney
2017-05-04 19:42 ` Jon Turney
2017-05-05 18:13 ` Achim Gratz
2017-05-06 0:20 ` Brian Inglis
2017-05-06 14:38 ` Marco Atzeri
2017-05-06 16:08 ` Brian Inglis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=de3fe890-42a5-ed5f-b1b7-3ad6ba03b5e2@dronecode.org.uk \
--to=jon.turney@dronecode.org.uk \
--cc=cygwin-apps@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).