Re: [Fink-devel] Updated dpkg and gettext packages

[Daniel M. <dm...@ne...>]

On Fri, Jul 24, 2009 at 04:35:53PM +0200, Sjors Gielen wrote:
> Op 24 jul 2009, om 16:20 heeft Martin Costabel het volgende geschreven:
> 
> > Sjors Gielen wrote:
> >> Hey Finkers,
> >> I didn't know which mailing list this mail was supposed to be sent  
> >> to, so please respond on the right one. Also, don't be alarmed if  
> >> my next e-mail comes from mai...@da... instead of da...@da... 
> >> , I'm subscribed there but this was more convenient for me.
> >> Attached is gettext017_and_dpkg.tar.gz, a tarball containing an  
> >> updated dpkg.{info,patch}, gettext-tools.info and libgettext8- 
> >> shlibs.{info,patch}. gettext-tools was updated to reflect gettext  
> >> version 0.17 - as opposed to gettext-tools-0.17 this one is not  
> >> statically compiled, but it compiles against libgettext8-shlibs,  
> >> the shared libraries for gettext 0.17. The dpkg package was updated  
> >> to not build gettext along with dpkg, but compile against  
> >> libgettext8 too.
> >> I also created a dpkg-bootstrap, but when I compared it with the  
> >> dpkg-bootstrap the current Fink bootstrapper contains, it was  
> >> almost exactly the same (no NLS support being the obvious most  
> >> important factor), so I left that one out. This set of packages  
> >> should still allow Fink to be compiled from scratch as long as  
> >> gettext is compiled and installed between dpkg-bootstrap and dpkg.
> >> I'm open to any constructive criticism and constructive hate mail.  
> >> This is one of the first packages I edited (let alone created) for  
> >> Fink, so bear with me if I made any serious mistakes, but I think  
> >> these ones should be free of them.
> >
> > Until now, there was a rule, even still quoted in your version of  
> > dpkg.info, that "essential packages cannot depend or builddepend on  
> > non-essential packages". This contradicts your new bdep line
> >
> > BuildDepends: fink (>= 0.24.12), libgettext8-dev, gettext-tools
> >
> > and this is also the reason why there was a line
> >
> > %p/bin/fink -y install gettext-bin libgettext3-dev libiconv-dev  
> > libncurses5
> >
> > in the CompileScript (a kind of covert build dependency.)
> >
> > -- 
> > Martin
> 
> 
> Hey Martin, thanks for your reply.
> 
> So uh let me get this straight. You have a policy of not allowing any  
> non-essential build-dependencies in an essential info file, but you do  
> need non-essential build-dependencies for dpkg, so instead of setting  
> them as build dependencies you hack them in the CompileScript to hide  
> them away from "public view"? (I'm not flaming you personally, of  
> course, just the person who came up with that, sorry if that's  
> actually you)
> 
> That's a situation badly in need of fixing. There are four solutions:

IIRC, the policy is to prevent deadlocks during the bootstrap
process. But the work-around works fine. In the past, we've had
horrible experiences with changing the bootstrap in any way...things
break that "shouldn't" based on how human readers understand the
process and code. So in the absence of a very compelling reason to
change bootstrap games, inertia (i.e., "it works as-is, and it
obviously is a careful/unusual bit of hackery") avoids pain.

> 1) Make gettext8-dev and gettext-tools essential. No go, gettext-tools  
> won't be made essential.

Also gettext8-dev cannot be essential. *No* "BuildDependsOnly" package
can ever be essential (or have anything Depends on them), and all
packages that contain headers and other compile-time parts of a
library *must* be BDO. Headers packages need to be able to be
uninstalled.

> 2) Compile gettext along with dpkg. Hacky, sucky, and we already have  
> gettext and everything, so, no go.
> 
> 3) Change the rule to be "essential packages cannot depend on non- 
> essential packages, but build-depends are OK" - no go, you guys don't  
> want this.
> 
> 4) since that rule is there to make it possible to completely  
> bootstrap Fink from source, we make an exemption for some packages in  
> that rule. Packages which *need* non-essential build-dependencies, can  
> have a -bootstrap counterpart, which *don't* need them so replacement  
> packages can still be built from scratch, albeit with less  
> functionality.
> 
> As it turns out, Fink already had a dpkg-bootstrap (which I found out  
> about after I wrote mine in the same way). dpkg-bootstrap has NLS  
> disabled, and as such only has fink itself as a build-dependency,  
> therefore matches the policy. Later in the bootstrap queue, dpkg- 
> bootstrap is used to install gettext-tools and gettext8-dev so the  
> real, complete dpkg can be built correctly. From that moment on,  
> gettext-tools and gettext8-dev and their dependencies can be removed,  
> they are only necessary for that one build.
> 
> Having a rule "all depends and build-depends need to be essential" and  
> sticking to it, no exceptions, makes for hacks to circumvent that  
> rule, as is clear from the current "fix". I think 4) is the way to go,  
> and the rule should be changed to "all depends and build-depends for  
> an essential package need to be essential - if that's not possible,  
> there must be a -bootstrap package whose depends and build-depends are  
> essential, and which can be replaced by the normal package later once  
> the build-depends can be correctly installed". Otherwise, I see  
> nothing but hacky fixes out of this, which defeat the whole purpose of  
> being able to bootstrap fink + essentials from scratch.
> 
> What do you think?

I think the present hacky fixes work, and I don't see a compelling
reason to change that isn't at best differently hacky. -bootstrap
packages are themselves a hack. The dpkg-bootstrap isn't a hack to
work around a dependency problem just in dpkg ("bootstrap of dpkg"),
but is necessary to be able to be able to compile before fink itself
exists ("source bootstrap of the whole world"). I'm also against
changing "must be able to bootstrap from source" because I don't see
any massive gain to offset that loss of portability or to future or
alternate systems or inability to nuke and totally restart from
scratch (or to customize) on a local machine.

dan

-- 
Daniel Macks
dm...@ne...
http://www.netspace.org/~dmacks