On Mon, Feb 17, 2025 at 10:47:04PM +0100, Julien Puydt wrote:
> Yes. Most upstream have little clue on what a best practice is, and
> need to be explained at length.
TBH I basically stopped reading here, this assumption is so flawed, the
(upstream) world is way more diverse.
--
cheers,
Hi,
Le 2025-02-17 22:47, Julien Puydt a écrit :
Their .tbz is working nicely -- but it isn't source anymore!
I think that we disagree on this one. Here the extent of source code and
build files changes between the .tbz and the git repository is
reasonably small and can be compared to what h
Hi,
On 2/18/25 00:21, Jeremy Stanley wrote:
Debian has, for legal and logistical reasons, decided that it cannot
distribute upstream Git repositories as its source packages, and
instead chooses to try to condense upstream's preferred form for
modification (back) into source tarballs.
If we "c
Hello,
On Mon 17 Feb 2025 at 08:22am -06, rhys wrote:
> "Actual practices" and "by fiat" are no different here.
The former refers to what they actuall work with, the latter refers to
what they claim is the preferred form of modification. These can come
apart.
> They do as they like with their
Hi,
Le lundi 17 février 2025 à 10:07 +0100, Julien Plissonneau Duquène a
écrit :
> Le 2025-02-16 21:03, Julien Puydt a écrit :
> >
> > - the previous version used %%VERSION_NUM%% in only three places,
> > the
> > new one uses it more, so it broke my previous hack -- ;
>
> As a matter of best pr
On 2025-02-17 08:25:03 +0800 (+0800), Sean Whitton wrote:
> On Sun 16 Feb 2025 at 06:18am -06, rhys wrote:
>
> > The potential for additional function is not relevant.
> >
> > If the upstream intends to distribute it with a tarball, that's
> > the "golden" package that downstream should base code
Le 2025-02-16 21:03, Julien Puydt a écrit :
- the previous version used %%VERSION_NUM%% in only three places, the
new one uses it more, so it broke my previous hack -- ;
As a matter of best practices, this should probably be defined in a
single place and not "hardcoded" multiple times with t
Hello,
On Sun 16 Feb 2025 at 06:18am -06, rhys wrote:
> The potential for additional function is not relevant.
>
> If the upstream intends to distribute it with a tarball, that's the "golden"
> package that downstream should base code upon.
The Debian project officially disagrees with you.
The
Le dimanche 16 février 2025 à 19:50 +0100, Julien Plissonneau Duquène a
écrit :
> Hi,
>
> Le 2025-02-16 17:00, Julien Puydt a écrit :
>
> > I have always considered the true way to know if you have the
> > source of
> > a package is: imagine you're stuck somewhere with a Debian mirror
> > and
> >
Hi,
Le 2025-02-16 17:00, Julien Puydt a écrit :
I have always considered the true way to know if you have the source of
a package is: imagine you're stuck somewhere with a Debian mirror and
no external link. Could you take over the development of the package at
hand?
Written like that it look
Julien Puydt writes:
> If you use autotools, you start with configure.ac and .in files. If
> upstream prepared the tree (as they generally do), you also get a
> libtool/configure, etc. From this, you can run ./configure && make &&
> make install ; that will do substitutions in the .in files. And
Le dimanche 16 février 2025 à 14:51 +, Colin Watson a écrit :
>
> This is a false dichotomy, though. It's perfectly possible to use
> both
> in conjunction with each other, by importing a tarball on top of an
> upstream git tag so that the differences between them are represented
> by
> a git
Le dimanche 16 février 2025 à 06:18 -0600, rhys a écrit :
>
> If the upstream intends to distribute it with a tarball, that's the
> "golden" package that downstream should base code upon.
>
> Going around that decision means subjecting all of Debian to code
> pulled from their repo outside of the
On Sun, Feb 16, 2025 at 10:39:59AM +0800, Sean Whitton wrote:
> I think that basing our work on upstream Git makes our source packages
> more useful, and more accurately reflects our commitment to providing
> the preferred form of modification for everything in our archive.
>
> If our work is base
Hello,
On Sat 15 Feb 2025 at 12:10pm +01, Stéphane Glondu wrote:
> Summary to other debian-devel readers: we are facing some upstreams that
> publish "official" tarballs that differ from what is in their git. The
> differences may include: variable substitutions, generated files... I guess
> this
On Feb 15, Stéphane Glondu wrote:
> On the other hand, insisting on using upstream VCS contents can lead to ugly
> hacks in Debian packaging, such as what you are describing. I must admit I
> usually use "official" tarballs to avoid these hacks (and maybe a little out
> of laziness).
In my own pa
Hi,
Le samedi 15 février 2025 à 12:10 +0100, Stéphane Glondu a écrit :
>
> My approach to this specific problem would be to add to dune the
> possibility to use some configuration file (or environment variables)
> as input for the substitutions, instead of directly querying the
> VCS. This con
Hi,
Le 2025-02-15 13:39, kpcyrd a écrit :
Diff between those two:
https://whatsrc.org/diff-right-trimmed/sha256:146d2d673358b7927d9a3c74e22b6b0e7f9a1aee2a4307afbe6ac07f12764130/sha256:599ff98cbab933a8b3640a084b12a5308a20795c192855ee454a8c1c16fa4dac
That divergence is reflected between the off
On 2025-02-15 12:33:16 +0100 (+0100), Daniel Gröber wrote:
[...]
> FYI: If all upstream wants is git metadata I like to introduce them to the
> wonderful, but obscure, git `export-subst` feature. See git-attributes(1).
>
> Works with forges, git-archive and everything.
>
> Example:
> https://gith
On 2/15/25 12:10 PM, Stéphane Glondu wrote:
I realize my previous email was a bit short: I was wondering if this
.tbz still source code because in the autotools world, package sources
come with configure scripts ready to run, but the good practice in
Debian is to regenerate those from configure.a
On Sat, Feb 15, 2025 at 12:10:06PM +0100, Stéphane Glondu wrote:
> > I fixed the elpi package by using something a bit hackish: I added git
> > as dep, and if I don't see a .git in the build directory, I create one!
> >
> > Here is what the execute_before_dh_auto_build target does:
> > if
21 matches
Mail list logo
