Re: Intent to package xfntbase, xfnt75, etc.
On Wed, 27 Jan 1999, Branden Robinson wrote:
> On Wed, Jan 27, 1999 at 08:01:28PM +0100, Santiago Vila wrote:
> > I intend to package all the dummy packages we have been talking about.
> > They match the packages that changed its name in the great X
> > reorganization.
>
> You'll do no such thing or I will take drastic measures. Those packages
> are MINE. If the dummy packages are going to be created, it's going to be
> me who does it.
>
> It only makes sense, since I am more familiar with the X packages than you
> are.
Branden, please calm down.
I hope we will agree at least that I don't have to ask for permission to
create packages as long as I don't upload them to Incoming.
They are available here:
deb http://master.debian.org/~sanvila frozen main
For these packages to be created, I did not need any familiarity with the
X packages, I just needed to know how did they change its names, and this
has been publicised widely.
BTW: Since you claim your "ownership" over these packages (funny: the
same packages you first said "they should not exist") I have put your name
in the Maintainer field. They are effectively yours, *iff* you want to
maintain them.
> [...]
> > * (From Branden Robinson) "Ok, don't worry, I think I should be the one to
> > do it, since I'm the X maintainer".
>
> Barring a better solution, I will be the one to do this. The xbase dummy
> package is already implemented in my current build tree and it makes sense
> for these all to be generated from the same source package.
On the contrary, I think that generating the dummy packages from another
source package will make the ordinary X packages to be much cleaner. But
this is only my opinion, I don't care much about this.
> > * "You should not create them because they are useless".
> >
> > Not true, since lot of people expect the old packages to be upgraded by
> > the new ones automatically, these packages are exactly which is needed
> > (with existing tools) so that the upgrade is done automatically.
>
> Non sequitur. The packages *are* useless in a purely functional sense,
> i.e., they are not ends in themselves, nor a means to anything but
> overcoming limitations in the packaging system.
Fine, let's agree that they exist to overcome limitations in the packaging
system. So what? Is there something wrong in overcoming limitations in the
packaging system? I think there should not be anything wrong with this.
> > * "Don't do it, they are ugly".
> >
> > Having an ugly thing does not mean it may not be useful as well.
> > Functionality is more important than aesthetics.
>
> The problem is ugly. So is your solution. I will concede that there may
> not be a pretty solution short of adding a feature to the packaging system.
> It does not follow that your proposal is the best of all possible
> solutions.
I will not claim that my proposal is the best one, but I hope you will
let me to think it is until I see a better one.
> > * "There should be some better way".
> >
> > Fine. Which one?
>
> Is there a way to have a dpkg --set-selections call lurk in the background
> until the current dpkg process ends, like update-menus does now? That
> would be a far cleaner solution.
> [...]
But then you would probably have to execute [I]nstall twice.
I don't see this would be cleaner.
--
"3d8b182588d86af3b97502c3448fa24f" (a truly random sig)
Reply to: