Hi, Am Sonntag, den 24.06.2018, 20:49 +0200 schrieb Mikolaj Konarski: > > sorry, I lost the context. What questions do we have? I might be able > > to answer some of them. > > Oh, great. Basically the rest of the email you commented > the first bit of. In particular, technicalities about easily > getting r0 or rN of a .cabal file or whole package. See below We can write a Haskell program that extract any revision from the index. What we do with that is our problem… not sure if Herbert can help us here. > But for you and other esteemed members of this group > I have the more fundamental question whether we want > to take advantage of revisions, or completely ignore them > or be in-between, as we are now on package-plan. > Neither me nor Herbert knows your needs as well as you do, > we can only observe occasional breakage and wonder It’s no longer my needs, Clint and others have thankfully taken over. But that will not stop me from giving my opinion :-) > > So my question is, do you think it will be useful to encounter that > > breakage early on (while updating package-plan), or do you feel it will > > introduce unnecessary complexity? It would be good to be able to distinguish between: * Uploading text-1.1 is fine, no other action necessary. Do upgrade text. * Uploading text-1.1 will break foo, because there is no version of foo compatible with text-1.1 yet. Do not upgrade text. * Uploading text-1.1 will break the Debian package for foo, but Hackage revisions indicate that this is just a question of bounds. Do upgrade text and patch foo. > > > * or incorporate revisions into our Debian naming scheme > > > and then apply the revision changes by the normal > > > upstream package upgrade process. > > > > Since our packaging workflow is based on upstream tarballs, this will be > > a little bit harder to be implemented, since there is no tarball for > > version foo-1.0r1 which we can download from Hackage. We would have to > > download foo-1.0r0 and metadata for foo-1.0r1 and repack. Not > > impossible, but it might not worth the trouble. No repacking needed, we can just import the revision as a patch, and do a patch release. This could be automated more, if someone feels the need. I am not sure if we are discussion things that are broken and need to be fixed, or things that are working, but confusing to newcomers (and hopefully the confusion is slowly disapperaing), or things that are working and understood, but can and should be improved? Cheers, Joachim -- Joachim “nomeata” Breitner • nomeata@debian.org • https://j.oach.im/
Attachment:
signature.asc
Description: This is a digitally signed message part