Packge review question (#642858)

[Sven Lankes]

On Fri, Oct 29, 2010 at 07:01:49AM -0400, Eric Sparks Christensen wrote:

>> While you're thoughts are certainly right, I'd tend to say that they're
>> not relevant for the review as the review is for the fedora packages and
>> it needs to be checked to work against what is currently in fedora.
 
> While I might agree that they aren't relevant for the review (the
> package meets current standards) I think we are just trying to figure
> out a way to make this a smooth transition and remedy a problem that
> was identified during the review.  But like Paul said, it's completely
> up to the packager.  If you want to maintain several packages of the
> same software then that is your decision.

I guess I'm just frustrated by the fact that a pretty simple review
takes that long even for a project where there are multiple people
interested in moving it forward.

Don't get me wrong - discussing drupal vs. drupal6 was important (hell -
I even stared the discussion) but now that we have come to an agreement
I guess that moving a little faster would be helpful in staying focused
on the issue at hand.

I'll try to do the rename-reviews that Jon has posted over the weekend.

>> As for the fedora/rhel-conditional - I'm not sure if it's still
>> neccessary to keep specs in sync across releases now that we can use
>> the wonders of git and it's merges but that's up for the packager to
>> decide and also not relevant in a fedora review request.

> Agreed.  However these were problems that were identified during
> review.  Had it been my package I would have wanted assistance on
> making my package as fluid as possible so I wouldn't have to remember
> that I have five different SPECs for the same package that all have to
> be individually changed when an update is presented.  Again, I believe
> this to be up to the packager to accept the recommendations or not.
> Flexifilter has already been approved so this isn't going to affect
> the status of that package, just trying to making maintenance easier.

My thoughts on having a single spec for multiple branches are that this
is in general a pretty ugly hack as it means that we either cannot use
new rpm/buildsystem features in newer branches or need to add lots of
if/else statements around their use.

Now that git has arrived it is perfectly reasonable to have a
full-featured current spec in master, have a slightly different spec in
EL-5 and still merge changes from master down to EL-5 even though EL-5
is different in some places.

So:

master has "Requires: drupal6"
f-14 has "Requires: drupal"
el-5 has "Requires: drupal6"

If that is in git then it would still be possible, to update master to a
new package-release, and merge the "new version"-changes down through to
el-5 without loosing the changed "Requires" line. So the need for "one
spec fits all" went down a lot with the move from cvs to git.

-- 
sven === jabber/xmpp: sven at lankes.net