Hi,
Troy Benjegerdes:
> My argument for this (besides my personal bias), is that a *feature* of
> mercurial is that history is immutable, while git has the feature which
> allows rewriting history. (my opinion is that's more of a misfeature)
>
Git doesn't rewrite history; it merely allows you to
On Sat, Nov 22, 2014 at 04:44:51PM +0100, Matthias Urlichs wrote:
> Hi,
>
> Troy Benjegerdes:
> > How hard would it be to add hooks/helpers to dpkg-buildpackage to know how
> > to deal with git and mercurial repositories, and deterministically generate
> > the 'source' tar.gz from the repo?
> >
>
Hi,
Troy Benjegerdes:
> How hard would it be to add hooks/helpers to dpkg-buildpackage to know how
> to deal with git and mercurial repositories, and deterministically generate
> the 'source' tar.gz from the repo?
>
Exactly: Get source by adding a vcs-git-commit: field which points to the
sources
On Fri, Nov 21, 2014 at 10:25:43AM +0100, Matthias Urlichs wrote:
> Hi,
>
> Russell Stuart:
> > Admittedly this meshes well with my experience that they are often
> > fairly lax about what they put in those tarballs. Their "make
> > distclean" scripts are often not as good as they could be
>
> O
On Fri, 2014-11-21 at 17:39 +0800, Paul Wise wrote:
> On Fri, Nov 21, 2014 at 5:25 PM, Matthias Urlichs wrote:
>
> > These days, they might just push their repo to github and let its machinery
> > generate the tarballs, which TTBOMK aren't guaranteed to be 1:1 identical to
> > another tarball of t
On Fri, Nov 21, 2014 at 5:25 PM, Matthias Urlichs wrote:
> These days, they might just push their repo to github and let its machinery
> generate the tarballs, which TTBOMK aren't guaranteed to be 1:1 identical to
> another tarball of the same commit that's downloaded a week later. Or a
> year.
I
Hi,
Russell Stuart:
> Admittedly this meshes well with my experience that they are often
> fairly lax about what they put in those tarballs. Their "make
> distclean" scripts are often not as good as they could be
Or they're better, in that a "make distclean" removes files like
*.min.js which a s
On Thu, 2014-11-20 at 13:46 +0800, Paul Wise wrote:
> On Thu, Nov 20, 2014 at 1:14 PM, Ben Finney wrote:
>
> > But a growing number of upstreams disagree, so those upstreams are
> > likely to be actively opposed to your recommendation to patches
> > which remove non-source files from the VCS repo
Quoting Salvo Tomaselli (2014-11-20 23:40:18)
>> Could you include some information about the upstream you are talking
>> about and the specific files you are concerned about?
>
> I am talking about this bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769830
That's a nice bugreport. It
On Thursday, November 20, 2014 11:40:18 PM Salvo Tomaselli wrote:
> > Could you include some information about the upstream you are talking
> > about and the specific files you are concerned about?
>
> I am talking about this bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769830
>
> The
> Could you include some information about the upstream you are talking
> about and the specific files you are concerned about?
I am talking about this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769830
The package has a lintian override that I suggested, on the grounds that the
incri
Quoting Ben Finney (2014-11-20 06:14:55)
> Paul Wise writes:
>
>> Upstreams that want to cater to end-users can distribute prebuilt
>> binary packages separately, in separate branches, zip/tarballs,
>> binary packages or "app" installers.
>
> You'll get no disagreement from me on that.
>
> But a
On Thu, Nov 20, 2014 at 1:14 PM, Ben Finney wrote:
> But a growing number of upstreams disagree, so those upstreams are
> likely to be actively opposed to your recommendation to patches which
> remove non-source files from the VCS repository.
I wonder about the basis for that disagreement. I thin
Paul Wise writes:
> Upstreams that want to cater to end-users can distribute prebuilt
> binary packages separately, in separate branches, zip/tarballs, binary
> packages or "app" installers.
You'll get no disagreement from me on that.
But a growing number of upstreams disagree, so those upstrea
On Thu, Nov 20, 2014 at 12:48 PM, Ben Finney wrote:
> In my experience, many upstreams have an aversion to an explicit build
> step, because they see VCS as not only a VCS, but also as an end-user
> distribution platform.
I would suggest that VCSen are for developers, packagers and advanced
users
Paul Wise writes:
> I think the best solution is to send upstream some patches that remove
> the files in question from the VCS and add commands to their build
> system to build the files in question from their source.
In my experience, many upstreams have an aversion to an explicit build
step,
On Thu, Nov 20, 2014 at 3:19 AM, Salvo Tomaselli wrote:
> Generic question. In my experience some upstream include some redistributable
> binary files. For example some binary stuff to create a .app on osX, minified
> javascript, and whatever.
Could you include some information about the upstream
Hi,
Quoting Salvo Tomaselli (2014-11-19 20:19:59)
> Generic question. In my experience some upstream include some
> redistributable binary files. For example some binary stuff to create
> a .app on osX, minified javascript, and whatever.
>
> Now, assuming that:
>
> - these files are redistribu
On 19/11/14 19:19, Salvo Tomaselli wrote:
> Generic question. In my experience some upstream include some redistributable
> binary files. For example some binary stuff to create a .app on osX, minified
> javascript, and whatever.
...
> - these files are redistributable, so there is no legal probl
Salvo Tomaselli writes:
> Should the upstream tarball be repackaged to remove them, or not?
First, note that the source package of any package in Debian is also
covered by the Social Contract. (Some people are surprised by this, so
it bears stating explicitly.)
Second, the Social Contract (in t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19/11/14 20:33, Marco d'Itri wrote:
> On Nov 19, Salvo Tomaselli wrote:
>
>> Should the upstream tarball be repackaged to remove them, or
>> not?
> They do not need to be removed at least if they can be rebuilt from
> the source in the package
On Nov 19, Salvo Tomaselli wrote:
> Should the upstream tarball be repackaged to remove them, or not?
They do not need to be removed at least if they can be rebuilt from the
source in the package (but they do not have to).
--
ciao,
Marco
pgpY1j9xGsHSF.pgp
Description: PGP signature
22 matches
Mail list logo
