#4924 build target for gdbm in rawhide
Closed: Invalid None Opened 12 years ago by hhorak.

Hi,

I'm going to build a new version of gdbm in rawhide, which has new soname numbers. perl and python are linked against old .so libs, so building gdbm directly would make problems in buildroot.

Can I have a target (e.g. dist-rawhide-gdbm) to build gdbm+perl+python safely?

Thanks,
Honza


Since there is no response so far, I'd like to ask, if my ticket is not on the right place? Or should I solve this issue somehow in a different way? If so, please, give me a direction.

Since there is no response so far, I'd like to ask, if my ticket is not on the right place? Or should I solve this issue somehow in a different way? If so, please, give me a direction.

I don't think a special build target will help bootstrapping things. for that, you'll likely need to provide both the new and old gdbm sonames somehow, either in a single monolithic gdbm package, or via some sort of (temporary) compat-gdbm rpm

I don't think a special build target will help bootstrapping things. for that, you'll likely need to provide both the new and old gdbm sonames somehow, either in a single monolithic gdbm package, or via some sort of (temporary) compat-gdbm rpm

Well, I wasn't much verbose about updating process, but this is my plan:
1. build python and perl WITHOUT gdbm support
2. build a new gdbm
3. build python and perl WITH gdbm support again

Then merge the new target with rawhide and build other packages against a new gdbm.

I've tested this on my localhost and it works. Sure, I can do the same in Rawhide directly, but I'd rather do it safely using the target.

Well, I wasn't much verbose about updating process, but this is my plan:
1. build python and perl WITHOUT gdbm support
2. build a new gdbm
3. build python and perl WITH gdbm support again

Then merge the new target with rawhide and build other packages against a new gdbm.

I've tested this on my localhost and it works. Sure, I can do the same in Rawhide directly, but I'd rather do it safely using the target.

OK, as long as "tested this on my localhost" meant you did you using mock. :)

OK, as long as "tested this on my localhost" meant you did you using mock. :)

s/you did you/you did so/

s/you did you/you did so/

Replying to [comment:4 rdieter]:

OK, as long as "tested this on my localhost" meant you did you using mock. :)

Yes, I did it using mock and then installed the built RPMs in VM to test that all dependencies are fine.

Replying to [comment:4 rdieter]:

OK, as long as "tested this on my localhost" meant you did you using mock. :)

Yes, I did it using mock and then installed the built RPMs in VM to test that all dependencies are fine.

OK, f17-gdbm tag/target created, wait for
http://koji.fedoraproject.org/koji/taskinfo?taskID=3364198

to complete, then kick off your new builds,
fedpkg build --target f17-gdbm

OK, f17-gdbm tag/target created, wait for
http://koji.fedoraproject.org/koji/taskinfo?taskID=3364198

to complete, then kick off your new builds,
fedpkg build --target f17-gdbm

Replying to [comment:7 rdieter]:

OK, f17-gdbm tag/target created, wait for
http://koji.fedoraproject.org/koji/taskinfo?taskID=3364198

Great, thank you for now, I'll let you know, as soon as all builds are ready.

Replying to [comment:7 rdieter]:

OK, f17-gdbm tag/target created, wait for
http://koji.fedoraproject.org/koji/taskinfo?taskID=3364198

Great, thank you for now, I'll let you know, as soon as all builds are ready.

all of this really should just be done in rawhide. side tags make it harder for secondary arches. and the cost of newRepos really outweighs any benefits for such a small number of packages.

all of this really should just be done in rawhide. side tags make it harder for secondary arches. and the cost of newRepos really outweighs any benefits for such a small number of packages.

Replying to [comment:9 ausil]:

all of this really should just be done in rawhide. side tags make it harder for secondary arches. and the cost of newRepos really outweighs any benefits for such a small number of packages.

No problem by me, just wanted to take less risk. Since no packages have been built yet, I can still do the thing only in Rawhide if you prefer -- just let me know which way should I go now, please :)

Replying to [comment:9 ausil]:

all of this really should just be done in rawhide. side tags make it harder for secondary arches. and the cost of newRepos really outweighs any benefits for such a small number of packages.

No problem by me, just wanted to take less risk. Since no packages have been built yet, I can still do the thing only in Rawhide if you prefer -- just let me know which way should I go now, please :)

Let's go with rawhide then. i'll nuke the target.

feel free to holler on irc if you need assistance or anything goes wrong. :)

Let's go with rawhide then. i'll nuke the target.

feel free to holler on irc if you need assistance or anything goes wrong. :)

Login to comment on this ticket.

Metadata