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
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
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.
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
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
10 matches
Mail list logo
