Simon Josefsson wrote:
> I think '9.1-dirty' would be better than '9.1' in this case, as a
> differentiator to '9.1', but I agree that probably most distributions
> will not like the '-dirty' word in there.
OK, we have a majority (PRO: Bruno, Simon; CONTRA: Bernhard). I'm
changing the suffix. This
Bruno Haible via Gnulib discussion list writes:
> `who --version` in Debian reports "who (GNU coreutils) 9.1". Should it report
> "9.1-dirty" instead of "9.1"? I don't think the Debian developers would find
> it socially acceptable to call most of their packages "dirty". And likewise
> for other
> + dnl Set variables documented in Autoconf.
> + AC_SUBST([PACKAGE_VERSION], ["$2"])
> + AC_SUBST([PACKAGE_STRING], ["$1 $2"])
> + AC_DEFINE_UNQUOTED([PACKAGE_VERSION], ["$2"],
> + [Define to the version of this package.])
> + AC_DEFINE_UNQUOTED([PACKAGE_STRING], ["$1 $2"
Bruno Haible [2025-01-26 04:36 +0100] wrote:
> Basil L. Contovounesios wrote:
>> Now I've noticed a separate issue with the VERSION_NUMBER docs:
>> running 'make dist' in a dirty worktree seems to get stuck in an
>> autoreconf loop involving GNUmakefile, judging from this message:
>>
>> INFO: ru
On 1/25/25 17:13, Bruno Haible via Gnulib discussion list wrote:
But from the perspective of the developer, there's a difference: Why
force a shaming term on a developer that makes adaptations?
I don't see it like that. It's not a statement about the code but about the
state
in the version co
Basil L. Contovounesios wrote:
> > And here's a further simplification: No more need to pass the PACKAGE name
> > twice in different places.
>
> Great, thank you! That means bootstrap can be reverted to not tracing
> gl_INIT_PACKAGE again, right?
Right. Thanks for noticing it. Done through the p
Bruno Haible [2025-01-25 04:08 +0100] wrote:
> And here's a further simplification: No more need to pass the PACKAGE name
> twice in different places.
Great, thank you! That means bootstrap can be reverted to not tracing
gl_INIT_PACKAGE again, right?
Another nice effect is that the 'redundant'
Bernhard Voelker wrote:
> If I pass a package to you with the name 'coreutils-X.Y-dirty.tar.xz',
> then what would that tell you? You cannot know and reproduce what it
> consists of.
>
> But if I commit my local change, and pass to you that patch and a
> package coreutils-9.6-8-gfbfd886e5, then o
On 1/25/25 13:57, Bruno Haible via Gnulib discussion list wrote:
>1) Most distributions do that. For example, coreutils in Debian has 3
patches
> [1].
>
>2) Making modifications is the essence of Free Software.
> [...]
> [1] https://sources.debian.org/patches/coreutils/9.1-1/
Of co
Bernhard Voelker wrote:
> Shipping a tarball with local changes which are not committed and pushed
> is ... yes, dirty work.
No, it isn't.
1) Most distributions do that. For example, coreutils in Debian has 3 patches
[1].
2) Making modifications is the essence of Free Software.
`who --
On 1/22/25 22:22, Bruno Haible via Gnulib discussion list wrote:
> [...] to call locally modified source code
> "dirty"?!
IMO "dirty" is not a wrong word here.
With regards to software deliveries, the tarball shall be made from an
officially
committed (and pushed, for what it's worth) version.
And here's a further simplification: No more need to pass the PACKAGE name
twice in different places.
2025-01-24 Bruno Haible
package-version: Simplify further.
* doc/package-version.texi (Propagating the package version): Recommend
use of gl_INIT_PACKAGE_VERSION inste
Basil L. Contovounesios wrote:
> I understand that projects using Automake can use VERSION in place of
> PACKAGE_VERSION, but I'm not aware of anything analogous to other
> PACKAGE_* definitions, such as PACKAGE_STRING or PACKAGE_URL.
> ...
> AC_INIT is documented as taking two mandatory arguments.
Basil L. Contovounesios wrote:
> > The fix is to add a definition
> >ACLOCAL_AMFLAGS = -I m4
> ...
> Do you know what it is about the new git-version-gen approach that gives
> rise to this? The redundant ACLOCAL_AMFLAGS were not needed with the
> previously documented approach.
The other *.m4
Bruno Haible [2025-01-23 21:47 +0100] wrote:
> Yes, and I hope that once the approach to let 'git-version-gen' be run
> at configure time (as opposed to autoconf time) is more widely accepted,
You have my vote ;).
>> IIUC this is because Gnulib's build-aux/bootstrap looks at AC_INIT
>> argum
Simon Josefsson wrote:
> > Yes, and I hope that once the approach to let 'git-version-gen' be run
> > at configure time (as opposed to autoconf time) is more widely accepted,
>
> Oh! Is that changed now?
Yes. It should have been clear from the list of fixes [1] and from the
new documentation (no
Bruno Haible via Gnulib discussion list writes:
>> From reading Gnulib's m4/init-package-version.m4 commentary I can
>> appreciate that it's a delicate dance
>
> Yes, and I hope that once the approach to let 'git-version-gen' be run
> at configure time (as opposed to autoconf time) is more wi
Simon Josefsson wrote:
> I had the same thoughts as you on the '*-dirty' keyword.
Thanks for mentioning it.
> However there is a subtlety: modifying a git-owned files lead to version
> changes, which after "make dist" in most projects leads to many files
> being different compared to upstream ver
Hi Basil,
Thanks for the feedback.
> > +One such propagated value is
> > +the value of the Automake-defined variable @code{$(VERSION)}.
> > +(There is also the Autoconf-defined variable @code{$(PACKAGE_VERSION)},
> > +but nothing except Automake ought to use it.)
>
> Why ought nothing else use P
Bruno Haible via Gnulib discussion list [2025-01-22 21:53 +0100] wrote:
> Spent the day thinking through the concepts and fixing all the problems.
Thank you for working on this!
I'm facing the following issues in adapting my project to the new
git-version-gen guidelines.
I've pushed a stripped-
Bruno Haible writes:
>> Spent the day thinking through the concepts and fixing all the problems.
>
> And another problem was that the version number for git repositories
> with local modifications was ending in '-dirty'. Which is problematic,
> because "dirty" is a word with a negative connotatio
> Spent the day thinking through the concepts and fixing all the problems.
And another problem was that the version number for git repositories
with local modifications was ending in '-dirty'. Which is problematic,
because "dirty" is a word with a negative connotation, and making
local modificatio
Simon Josefsson wrote:
> The only way to really be sure is to continously do 'make release' etc
> in CI/CD from fresh git and compare with your local tarballs. I do this
> for several projects (libidn, libtasn1, inetutils, ...), and for
> inetutils I get reproducible tarballs (with some uncommitte
Simon Josefsson wrote:
> > Maybe a doc/git-version-gen.texi is the answer here... and thinking
> > through the concepts a bit more.
I replied:
> Let me start doing that.
> ...
> Next, what are the problems?
Spent the day thinking through the concepts and fixing all the problems.
* The comment a
Hi Simon,
> Maybe a doc/git-version-gen.texi is the answer here... and thinking
> through the concepts a bit more.
Let me start doing that.
First, what is the current status?
* The files:
- .tarball-version contains the version the maintainer wishes "make dist"
to produce — or, if absen
Bruno Haible via Gnulib discussion list writes:
> Simon Josefsson via Gnulib discussion list wrote:
>> +EXTRA_DIST += $(top_srcdir)/.version
>> +BUILT_SOURCES += $(top_srcdir)/.version
>> +$(top_srcdir)/.version:
>> +echo '$(VERSION)' > $@-t
>> +mv $@-t $@
>
> Wait a moment. Befor
Simon Josefsson via Gnulib discussion list wrote:
> +EXTRA_DIST += $(top_srcdir)/.version
> +BUILT_SOURCES += $(top_srcdir)/.version
> +$(top_srcdir)/.version:
> +echo '$(VERSION)' > $@-t
> +mv $@-t $@
Wait a moment. Before putting this into a Makefile fragment, we should
fix it fi
27 matches
Mail list logo
