State of the Sourceforge package [was: Release-critical Bugreport for February 22, 2002]
Henrique de Moraes Holschuh (2002-02-22 15:26:52 -0300) :
> On Fri, 22 Feb 2002, Roland Mas wrote:
>> > Package: sourceforge (non-US/main)
>> > Maintainer: Roland Mas <lolando@debian.org>
>> > 134058 [ ] sourceforge: change to nsswitch.conf makes system unusable
>> > 134724 [ ] sourceforge: Contains conffiles outside /etc
>>
>> Fixed in incoming.
>
> The last time I tried this package, it was so far from being release-ready
> it was not funny. It was half-finished at best... I had to purge all the
> auto-install stuff from the postinst, rebuild, install that and then go
> through the install helpers one by one, and fix whatever they didn't manage
> to get it right.
>
> And that was quite a lot of stuff (e.g: passwords for the bots and admins
> were not set up correctly, the scripts used a royally screwed up ldif that
> slapd wouldn't even allow into the db because it failed the schema checks,
> and so on). I didn't bother filling a bug, since it was so damn obvious
> those scripts were not finished yet. Maybe I should have.
Other people did it for you (#134058 says approximately the same thing
as your last two paragraphs).
> This was less than a month ago. Did you guys get it up to shape
> this fast?
We did fix a lot of things. Some other packages we depend upon also
did. No known brokenness is found.
> Also, are you guys still outragerously violating policy by running
> scripts that change just about every important part of the system
> (including config files of other packages) on the _postinst_ ?
See bug #134058 (now closed). Short answer: not unless the user
chooses to. Long answer: there will soon be an even better scheme of
doing things. There already is, in another branch of the package.
> (hint, remove the autoconfig stuff from the postinst, and tell the
> user to run the config wrapper by hand).
And then leave the package in a broken state? Not unless the user
chooses to. Which is what was done: he's asked whether to let the
scripts change his config files (and the default answer is "no").
> I am grateful at the work the debian-sf team is doing, and it is MUCH easier
> to setup even that broken package I tried, than doing it from scratch. Still,
> it was not something we should have in the next stable the last time I
> looked at it.
If you feel that way, and can point out precise bugs that should
prevent this package to be released with woody, then please submit
reports. We spend a tremendous amount of time testing, deinstalling,
reinstalling, purging, reinstalling from scratch, upgrading and so on,
but the package depends on so many other packages that if any one of
then is broken (and I'm *not* trying to shift blame on slapd) the
whole stuff cannot work. And I'm reluctant to add cruft to a package
just to check that some daemon works. This is Debian. It's supposed
to work. If it doesn't, I'll report it as a bug on the other package
in order to make that other package work.
> Well, I will give the new package a try this weeked. I hope you guys
> have fixed it all, an easy-to-install debian-sf would be a damn good
> thing.
Again, if you find non-working stuff, please report. I won't try to
push sourceforge into woody if it's not releasable. I'll try to make
it releasable instead. If I fail to do so, it won't be released,
period. Hopefully it'll be released with woody+1, which, given all
the proposals to make the release times shorter, should be released
next month or so ;-) In the meantime, there's usually people on the
#Debian-SF channel, if you want info/support/instant bug reporting.
I hope I didn't sound aggressive. It's not what I have in mind.
Roland.
--
Roland Mas
Vampyres are just the same, the only real difference being that they can't
spell properly. -- in Carpe Jugulum (Terry Pratchett)
Reply to: