On 8/1/07, Paul Mattal wrote:

Jan de Groot wrote:

...

Thanks for not using checkpkg to check that the soname bumped from .so.7 to .so.8. We need to rebuild all packages that link to libflac. This should have gone to testing, and you would have known if you had used checkpkg.

I did use checkpkg. This is how I noticed this, and why I sent this email.

It sounds like you expected I would do something different. If so, we should put that in a document somewhere so that we can all know what to do. If such a document exists, please point me to it.

Yes, someone please document this.

On 8/1/07, Jan de Groot wrote:

If they go to current directly instead, the packages that depend on it should be rebuilt during the same run of db-extra/db-arch. Wasn't this one of the reasons we have testing?

Any reason /arch/db-* can't/shouldn't run checkpkg themselves, and force you to say "/arch/db-extra --force" or something if you want to add something to the db that has a sobump? It seems like namcap is something you run locally to check out your package, but errors are not blockers to release of a package a lot of the time. checkpkg's errors are almost usually a blocker to release. I think if it has an error in checkpkg, just send an email to arch-dev, and add it to [testing] until everything is caught up. This slight change in workflow will greatly increase the "stability" of releases that everyone has been talking about on the bbs/ml/#archlinux-meetings. // jeff -- . : [ + carpe diem totus tuus + ] : .

Jan de Groot wrote:

Well, usually, when a basic package like a codec where >15 packages depend on has a sobump, these packages go to testing first to give developers chance to rebuild. If they go to current directly instead, the packages that depend on it should be rebuilt during the same run of db-extra/db-arch. Wasn't this one of the reasons we have testing?

How do you know that >15 packages depend on this? It seems to be it would be really good to have something on the website where we can query all packages that depend on another package, recursively. Otherwise I don't see how we can expect people to divine this information. I've been told various things about different [testing]. In this case, it seemed like the upgrade and the email would allow those needing to rebuild time to do it without significant trouble. Anyhow, as I've said, I'm happy to conform to any identifiable documented guidelines we agree upon, or to consider suggestions to do things differently. - P

Damir Perisa wrote:

Wednesday 01 August 2007, Paul Mattal wrote: | How do you know that >15 packages depend on this? It seems to be | it would be really good to have something on the website where we | can query all packages that depend on another package, | recursively. Otherwise I don't see how we can expect people to | divine this information.

pacman -Qi flac gives you this:

Required By : akode arson gst-plugins-flac libsndfile xine-lib dssi easytag k3b kdemultimedia libsamplerate mkvtoolnix sdl_sound tunepimp jack-audio-connection-kit mpd ardour vorbis-tools

I knew about this.. but doesn't this only tell you for packages you happen to have installed on your system? And does it work recursively?

but in addition you should know what pkgs you maintain and what consequences they have.

True. I just took over flac, though, so I need to get my head around the whole thing. Over time these sorts of problems work themselves out. I like the page Simo pointed to, as a good compromise. It at least gives us some corporate memory about packages moving forward. If I get a chance, I will tool up a "meta" developer page with links to all pages that contain current info that developers should be looking at. The problem is, things change over time.. being a developer is very different now than it was when many of us joined up, and it's helpful to have some central repository of shared knowledge that we can rely upon, all linked from one central place. - P

Simo Leone wrote:

On Wed, Aug 01, 2007 at 02:01:45PM -0400, Paul Mattal wrote:

...

at. The problem is, things change over time.. being a developer is very different now than it was when many of us joined up, and it's helpful to have some central repository of shared knowledge that we can rely upon, all linked from one central place.

Not to sound overly sarcastic or anything, but I call that a wiki...

It's a good point, but wikis in general and this one in specific turn out to be unwieldy. Useful wikis usually contain tons of information, and not the kind that can be kept in a person's mind at all times when packaging. So I would suggest we either need a better guide or less expectation that things will be uniform. I'm actually quite okay with the latter.. people here just usually make things work when they see things broken. It all works out. - P

On Wed, Aug 01, 2007 at 10:43:27AM -0400, Paul Mattal wrote:

Jan de Groot wrote:

...

Thanks for not using checkpkg to check that the soname bumped from .so.7 to .so.8. We need to rebuild all packages that link to libflac. This should have gone to testing, and you would have known if you had used checkpkg.

I did use checkpkg. This is how I noticed this, and why I sent this email.

It sounds like you expected I would do something different. If so, we should put that in a document somewhere so that we can all know what to do. If such a document exists, please point me to it.

http://archlinux.org/wiki/Package%20Upgrades/ of course no one pays any attention to that anymore, but it's the thought that counts, right? Why run checkpkg and all that garbage every time, keep it simple and record the ones you found so whoever upgrades it next time will have a head start and know what they're getting themselves into. -S

Wednesday 01 August 2007, Simo Leone wrote: | Why run checkpkg and all that garbage every | time, keep it simple and record the ones you found so whoever | upgrades it next time will have a head start and know what they're | getting themselves into. exactly my point - i do not want to be forced to run checkpkg if i as a human being feel i do not want to for a certain update i'm _sure_ it is ok. actually... the best way to check for so-name changes is the contact with the developement leader of a project. that's how i figure out if a pkg triggers rebuildings to other pkgs in most cases. - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

Wednesday 01 August 2007, Jason Chu wrote: | On Wed, Aug 01, 2007 at 07:14:54PM +0200, Damir Perisa wrote: | > Wednesday 01 August 2007, Simo Leone wrote: | > | Why run checkpkg and all that garbage every | > | time, keep it simple and record the ones you found so whoever | > | upgrades it next time will have a head start and know what | > | they're getting themselves into. | > | > exactly my point - i do not want to be forced to run checkpkg if | > i as a human being feel i do not want to for a certain update | > i'm _sure_ it is ok. | | I'm glad that you feel it in your very soul. But a computer will | be able to tell you for sure, it isn't human. right you are... i just fear the point where human overriding of something is not longer possible because of the rightness of something... | While I understand your feelings, if the check wasn't as invasive | as the current checkpkg (like, run on the server) wouldn't it be | better to verify everything and then make exceptions for the cases | you get all touchy feely about? sure, absolutely! checkpkg as it is now i don't like because my internet connection is not the fastest and my cpu almost all the time used (therefore also 66°C most of the times)... that's why i compare FILELISTs instead of running checkpkg for cases i'm not sure about so-name changes... my argument is purely egoistic and out of my comfort. would i be having a high-speed internet and a up-to-date CPU (actually my new laptop that should come every day will have enough CPU power), i wouldn't mind rebuilding old versions to compare so-names... | > actually... the best way to check for so-name changes is the | > contact with the developement leader of a project. that's how i | > figure out if a pkg triggers rebuildings to other pkgs in most | > cases. | | If they get back to you in a reasonable amount of time they usually do... they feel all too excited and like to get feedback anyway. | and | remember every library that's changed between one version and | another... they should know.... if not, maybe they should run checkpkg before releasing soemthing they do not know what it is :) | They're also human. all of them? :-) lol! - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><