Opened 14 years ago

Last modified 13 years ago

#5 accepted defect

gdal-1.8.0-2 depends on postgresql-devel instead of postgresql84-devel

Reported by: hopfgartner Owned by: mbaudier
Priority: major Milestone: 5.7
Component: dependencies Version: 5.6
Keywords: Cc:

Description


Change History (6)

comment:1 by mbaudier, 14 years ago

Component: upstreamdependencies
Status: newassigned

Could you please detail a bit more why it would be required?

It did not cause any problem so far, and I was expecting that there was a way to stay compatible with both.

If this is not the case, I have no pb with changing it since all users are probably using postgresql because of postgis which requires postgresql84 anyhow.

comment:2 by hopfgartner, 14 years ago

My personal problem (I have to rebuild GDAL locally since I need support some non-FOSS formats) is that postgresql-devel conflicts with postgresql84-devel and I need the latter one for a other dependencies. Not a big issue, since it takes a fraction of a second to change that BuildRequires locally.
I do not know, if there are drawbacks using postgresql-devel, in particular I do not know if the on-the-wire format changed from PostgreSQL 8.1 to PostgreSQL 8.4 and if those hypothetical changes do have any practical impact.

comment:3 by mbaudier, 14 years ago

This is ok for me.

I suggest that we notify on the list that we will change this in order to leave a chance to somebody to comment on a possible impact.

Too bad that you need to rebuild locally.
Maybe we should set up a non-free repo for such stuff? (assuming it is redistributable)
The problem is always that I don't want to loose sleep thinking on what is my (legal) responsibility in distributing non-free stuff...

in reply to:  3 comment:4 by hopfgartner, 14 years ago

Replying to mbaudier:

This is ok for me.

I suggest that we notify on the list that we will change this in order to leave a chance to somebody to comment on a possible impact.

Good idea, I'll do that.

Too bad that you need to rebuild locally.

That's not a problem at all. Having ease to rebuild src.rpm really helped me a lot here and I can live with that.

Maybe we should set up a non-free repo for such stuff? (assuming it is redistributable)
The problem is always that I don't want to loose sleep thinking on what is my (legal) responsibility in distributing non-free stuff...

Personally, I would not take the risk. All we can do is to keep the src.rpm in shape, so that adding one format reduces to --enable-xyz. Or we could adopt Remi's approach, like in https://github.com/remicollet/remirepo/blob/master/php/php.spec, around line 32.

comment:5 by mbaudier, 13 years ago

Milestone: 5.7
Version: 5.6

comment:6 by mbaudier, 13 years ago

Status: assignedaccepted
Note: See TracTickets for help on using tickets.