release tarballs

[ghost]

Hi,

it would be great if you could make releases once in a while so that packaging is easier and does not require checking out a commit of this repository.

Thanks

[GrayHatter]

any reason you can't use https://github.com/irungentoo/toxcore/archive/master.zip

[GrayHatter]

https://github.com/irungentoo/toxcore/archive/master.tar.gz might work as well, but I haven't tested it.

[felix-salfelder]

same situation here (packaging for major GNU/linux distro). git snapshots are not suited well.

• snapshots are inofficial
• version is missing
• history is missing,
• there's no checksum,
• files generated by autotools are missing.

(maybe there are more reasons)

... so could you please make dist and provide tox-0.0.0.tar.gz (preferrably at a canonical place such as https://tox.chat/download.html?) also: please merge #1609

thank you!

[GrayHatter]

None of the above are too likely here. You should reopen this issue on
https://github.com/TokTok/toxcore

On Sun, Aug 21, 2016 at 1:32 AM, felix notifications@github.com wrote:

same situation here (packaging for major GNU/linux distro). git snapshots
are not suited well.

• snapshots are inofficial
• version is missing
• history is missing,
• there's no checksum,
• files generated by autotools are missing.

(maybe there are more reasons)

... so could you please make dist and provide tox-0.0.0.tar.gz
(preferrably at a canonical place such as https://tox.chat/download.html?)
also: please merge #1609 #1609

thank you!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1610 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAO20K4iq3ah6DlTxFHWNvs_vl7ld9wKks5qiA0lgaJpZM4JpKtU
.

[felix-salfelder]

what is TokTok? (never heard of it)

[GrayHatter]

it's a fork that's see development

[felix-salfelder]

thanks. seems to make more sense to try here.

[ghost]

For a reason, see this comment Tox/tox.chat#116 (comment)

[ghost]

As Tox/tox.chat#116 has been closed, can we continue this dicussion here?

In addition to the reasons given before: how should packagers know which commit is good, which commit builds and which commit doesn't? It brings a stability to users and packagers to know what's good and what isn't, to rely on a single file rather than on commit ids.

Also something to consider:
A developer (hopefully) puts thought and care into making a release, marking it as a definite point to build on. Developers generally do not put the same care in git commits, because bugs introduced in them can easily be fixed with another commit, or worse, by amending a commit (changing its commit ID).

Adding to this, if your choice is to not release tarballs/archives at the moment, it is okay for us. I was just suggesting to consider it. We will be working with whatever you choose to provide.

[ghost]

I am closing this now. Anyone who feels this needs to be addressed should reopen it.

#1610 (comment)

[felix-salfelder]

i have started some packaging here. maybe there are 10,000 users waiting for a release, maybe it's just me. anyway: asking here seems to be a natural thing to do.

(I don't know, how to reopen. perhaps only the issue/project owner can do such things?)

[ghost]

I have packaged it for Guix, currently pending review.

Why I closed this is that it is upstreams decision not to do a release. As a person who packages their software I can make suggestions and ask, but I want to work as close as possible with them. So if they decide not to do release numbers and prefer git, svn, fossil, or whatever instead of tarballs it is their choice and I have to work with that. As much as I'd love to see versions to which one can point and use them (see thread), I have to accept their choice for their software.

@felix-salfelder In Guix we can include software which is in version control, pinned to a checkout and its calculated hash. I assume Debian has equal options, or is this a major block for you?

[felix-salfelder]

Why I closed this is that it is upstreams decision not to do a release.

havent heard a reply from a/the presumable author yet. so actually i don't know.

In Guix we can include software which is in version control, pinned to a checkout and its calculated hash

what do you do if the library interface changes in a newer version? without version numbers, this will likely break all of the reverse dependencies, when updating the library package. it's a question of time, but obviously, this will happen. who will be responsible then?

note that debian (for good reasons) ships and uses shared libraries whenever technically possible.

i think if somebody is willing to take care of a package with extra complications, (s)he is welcome. i consider messing with nontrivial internal things during packaging close to forking. and i am not willing to maintain a fork.

typically upstream authors understand the problem sooner or later. configure.ac clearly indicates that there was at least one author involved, who knows how to do releases and versions properly. so as long as these traces of sanity are in place, i'm sure i will prefer waiting to taking any other action.