Am 22.03.2018 um 15:40 schrieb Guillem Jover: > Hi! > > On Thu, 2018-03-22 at 12:47:44 +0200, Lars Wirzenius wrote: >> On Thu, 2018-03-22 at 09:58 +0100, Andreas Tille wrote: >>> I admit I do not agree with this and it was discussed here before. Can >>> we please agree that anonscm.debian.org remains a valid URL and stop >>> starting another round of package uploads for the sake of changing Vcs >>> fields. > >> I'm repeating myself, but could we please find another way to store >> this information than in the source package? I'd like to see all of >> the following stored somewhere else than the source package: > >> * Maintainer, Uploaders >> * Vcs-* >> * Homepage >> * debian/watch >> >> Possibly also Section and Priority.
Yes! > I'm not sure now if this also has been said before, but I'm happy to > repeat it in any case. :) I'd very strongly object to completely moving > those fields out of the source packages, because it means when you get > or have a source package lying around then it's missing important > metadata and it stops being standalone, which would require checking > somewhere online, and you might first need to infer which distro/repo > was this coming from. I'll happily take outdated data than no data any > day, because usually you can use that outdated data to trace your way > to the current one, not so if it's missing. You need online access to make use of the above information in any way. If you want to contact the maintainer you need internet access, if you want to visit the upstream homepage you need internet access, etc. These information are distribution-independent because they are either the same like "Homepage" or you could simply look them up if you define a common and central platform like tracker.debian.org as your main hub for external/additional/random information about package X. Look how Fedora have solved the same issue. They have https://src.fedoraproject.org/ and everything is organized by convention in an identical way. There is no need for them to put the same information into their spec files and they also have derivatives. Be sure Ubuntu or Mint users don't care about our Vcs or maintainer fields as well. > >> All of the above can change and it's silly to have to make a source >> upload to change them. They also easily get out of date and so are >> likely out of date for a stable release. > > Yes, it might be silly to have to upload a package just and only to > update that information, or having that data being permanently > out-of-date on stable. But this problem can be easily solved already, > the archive, and most (if not all!?) repo managers have had the > concept of overrides for a very long time, starting with things like > dpkg-scanpackages/dpkg-scansources! I don't understand why some people always think it is smart to create or use some new program or tool to solve a problem when the most efficient way would be to solve a problem non-programmatically. Reduce the complexity by defining conventions which all developers have to follow in Debian like maintaining external information in tracker.debian.org instead of the source package. A switch of Vcs platform would become a trivial matter in the future by replacing some strings on the server. It would take seconds and could be solved by a single person. I have already seen hundreds of uploads just for the sake of changing the Vcs-fields in debian/control. That is crazy. > The only thing needed would be to provide that additional updated data, > to DAK so that it can override appropriately. Although ftp-masters got > such requests in the past and were apparently not very enthused (although > I don't see any reasoning behind the wontfix), maybe because of the > required manual work. Perhaps if the data was fed in a similar way how > debtags data is fed then they'd have less of an issue? Dunno really. > > <https://bugs.debian.org/81391> > >> I envision a service, metadata.debian.org, with a suitable >> authenticated API to allow Debian package maintainers to update the >> information, and having tracker.debian.org, dak, and other parties >> fetch the data from metadata service, for inclusion in, say, Packages >> files. > > Sure, as long as it only provides up-to-date data to _override_, and not > the entire and only canonical place to store it. > >> I think this would be a better thing to spend time on than talking >> again about keeping anonscm around. > > And this is still missing the point, as I've also said in the past. The > worst part of this is not IMO to have to update the Vcs fields, which > TBH is one more time too many. It's that it implies any downstream, any > service pulling from the repo, any mirror and checkout, needs to be > noticed in time (while the redirect is in place, because there's now > recommendation to remove it after the next upload!) and then someone or > something needs to update all those references lying around. :( If you store this information on tracker.debian.org there would be no delay and no inconvenience for downstreams at all. In most circumstances they have their own "tracker.debian.org" service like launchpad.net. Things like the maintainer or Vcs field get overridden anyway and other information could be provided via a simple API and thus kept in sync with their services.
signature.asc
Description: OpenPGP digital signature
