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@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
