Heads-up: brand new RPM version about to hit rawhide

[Les Mikesell]

Nicolas Mailhot wrote:

>> First, before I respond to the rest of this, keep in mind that the
>> "overwhelming majority" of packages needs to be quantified.
> 
> How about the 9/10th of packages I've been involved with since I used
> RHL or Fedora (I think I've passed my decade of use and packaging now)?
> 
> I'll grant you a few of them are clean SCM dumps. Since I had to rewrite
> upstream's release script myself (and get it merged) to make sure it was
> always the case.

If you can't reproduce a release exactly from a tag in your repository 
you've seriously missed the point of version control.  You might even 
make a good argument that for sources that live in a distributed SCM, 
that is the "preferred form of the work for making modifications to it" 
as required by the GPL.

On the other hand, I've heard svn mentioned in passing here and I don't 
think it will do what you need without some help - perhaps svk or pushmi 
would get a usable mirror copy where you can add a local branch for a 
build, but I'm not sure how you would do subsequent redistribution.

>>  And to be honest, I
>> would be very surprised to find many projects that do have any
>> significant difference between a tagged release in the SCM of their
>> choice and their tarballs.
> 
> It does not need to be huge to cause no end of QA and maintenance
> problems.

But upstream will be having these problems anyway and you inherit them. 
  Some good examples of how to avoid them all the way to the packaged 
versions would be good for everyone.

> No.
> What matters is we pick the version upstream intends us to use.
> What matter is we pick the version upstream checked for problems before
> publishing (even if that involved some dirty upstream massaging)
> What matters is we use the same upstream version as everyone else so we
> benefit from the collective QA work the community does.

These are all precisely why you have a VCS that manages the details for you.

> What matters is our users know exactly what they get and not dumps of
> VCS soup.

I'm not sure what you mean here.  A tarball with magic tweaks might be 
OK if it is perfect and will never need ongoing maintenance, but that is 
never the case.  If you work directly with the VCS you can at least see 
what is changing and usually why.

 >> It's currently a
>> hard requirement *solely* because we haven't integrated cloned SCM repo
>> support in Fedora yet, and since we are talking about implementing
>> exactly that support, it negates this "hard" requirement.
> 
> You've certainly lived a sheltered life with no contact with the kind of
> code one can find in the internet.

As long as the old method continues to work, what's the problem with 
adding a way to improve it going forward?

>>> As long as your system can take this into account I don't think anyone
>>> would mind having a more modern way to manage the stuff we put around
>>> this upstream archive.
>> Sorry, but if I do the work, then I'm writing it to eliminate the
>> tarball.  You don't have to switch your package to this new method if
>> you don't wish, but I'll be switching my packages over and they will
>> never touch a tarball again.
> 
> If you don't want to listen, don't complain you're not heard.

If you don't eliminate the tarball, you aren't going to make a big 
improvement.  Why not leave it as-is where you can't do anything better 
but add the mechanism to improve things when possible?  This doesn't 
break anything and lets you take advantage of upstream changes that will 
happen (or not) at their own pace.  You'll need to come up with a 
different concept for the src rpms though.  Would they contain build 
commands to extract the tagged source from a separately stored (and 
available) mirrored scm repo for each project?

-- 
   Les Mikesell
    lesmikesell at gmail.com