[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#809623: RFS: telegram-purple/1.2.3-1



Hello,

They generate the orig tarball.
The watchfile is to check for the newest version.
These are unrelated things.

no. they are completely related things.
uscan downloads the tarball from the watch file, and if the uscan downloaded tarball doesn't fit your needs
you have to call the repack script directly from the watch file.
with a get-orig-source target
https://wiki.debian.org/onlyjob/get-orig-source

Oh, wow. This will take a bit time until I grasp everything well enough to publish something with this :P

Most prominently, I don't like the "everythingisoneline" approach of the watchfile. I guess someone has already suggested changing it to the "usual" YAML-based approach?

this is my virtualbox watch file

version=3

opts=downloadurlmangle=s/^/http:/,dversionmangle=s/-dfsg\d*$//,uversionmangle=s/-.*// \
http://download.virtualbox.org/virtualbox/([\d\.\-]+)/VirtualBox-([\d\.\-]+).tar.bz2 \
debian /bin/sh debian/get-orig-source.sh

I... I believe I understand this. However, testing this will be a pain, and automatic testing probably impossible.

Is there some kind of established "best practice" for testing these? Or is the best practice just to "run by hand until it works, then wait until it breaks for DEHS"?

I know and agree that d/genorigtar.sh and d/rawtar are ugly, and they
will be dropped in the next version, in favor of relatively clean
chaining of git-archive and tar --concatenate.
(Obviously not part of the build process, so no need to put any of that
into Build-Depends.)

sure, even better, maybe if you integrate with watch file.

I can do that, sure. Can you tell me who profits from this, though? It's a bit demoralizing to have to write and test things like these if noone will ever profit from this.

I understand that d/watch is needed by DEHS to monitor how outdated the Debian repository is, in some sense. So I wrote a d/watch for that, and made sure it works and will continue to work.

I also understand that some maintainers prefer working with uscan to fetch and integrate the newest upstream version. But that doesn't apply here, as the preferred mode of updating is doing a "git pull".

My script would probably do the following thing:
- delete the file fetched by uscan, since it's utterly incomplete
- use the upstream version to clone (as in git-clone) the repository
- ./configure && make dist || (echo "Too old upstream version; doesn't support orig tarballs yet."; exit 1)
- delete all temporary files
Ugh.

And all that so that someone can say "dh get-orig-source".
So, who does this? (And can I assume git to be installed? I don't like having such a big b-d ...)

BTW submodules should in my opinion be considered as different sources, and packaged
separately.
Otherwise you will have a mess of files with no common history, difficult to track and fix
(specially for security issues)

Already extensively documented in d/README.source

In short, the reason is: tgl ("the" submodule) is way too unstable and volatile to ever be packaged separately.

There is only one other program that might enter the Debian repository (tg-cli, I don't see any RFP or ITP for it) will never be used together with telegram-purple, and will most definitely never use a compatible version of tgl.

Currently, we assume that the builder eventually invokes ./configure
with whatever arguments he pleases and the usual semantics. This
approach does not need anything explicit in d/rules.
autoreconf is only called when we change configure.ac, in which case the
new configure-script will be put into git. At no point, there's a need
for the "user" (here: builder) to call auto{,re}conf.

Oh. Maybe the entry "autotools-dev" in Build-Depends is superfluous, then?

exactly, but you need to call autoreconf each time you configure the script.
it might sound silly to you,  but in case a new architecture is added in Debian
(e.g. recent ppc64el and arm64), your scripts will be outdated,

None of our scripts assume any architecture or have a list of all of them. What part of which script would become "outdated"? What would change?

BTW the version should always be a -1 revision, until the -1 reaches debian (specifically new queue)

Hmm, but this makes it easier for me to track which versions there were.

But okay, I'll push the next version as 1.2.4-1 if you wish.

you don't have to bump the debian revision, this will make harder for a sponsor to track it, and
useless for Debian users (they won't find the intermediate releases)

Huh? I'm confused. I make sure that all versions have a different number, and go increasing as per dpkg --compare-versions. Why is it *harder* to track progress?

I mean, sure, I can change my behavior regarding that, I just think it's a good idea if I also know the reason for it :P

Regards,
Ben


Reply to: