[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]


On Thu, Mar 04, 1999 at 07:26:34PM +0100, Santiago Vila wrote:
> > ITYM does not support it *properly*, [...]
> Well, I mean there is not a way to tell dpkg "Package Foo is the same as
> package Bar and you should consider them as being one and the same".
> Since this is not the case, 


> people who, after all, insist on renaming
> packages usually rely on already existing dependencies.

I don't *insist* on renaming, I just thought that I should 'commonize'
the names while I'm at it. It is clear to me that if something can't
be done that I shouldn't force it. But there is no better way than to try.

> I suppose that renaming xpm4g to libxpm4 would work, as long as you make
> libxpm4 to provide xpm4g, but since we need versioned provides, I think it
> is a bad idea (would not be much better to wait for "xpm5" and use the
> "right" names only for the new libraries?).

Didn't you read my last message? It is possible that these two minor
versions live together in peace - there is only one problematic symlink.

> Regarding the libc5 libs: Since they will disappear sometime soon,  

I wouldn't bet on it, that runtime oldlibs will disappear soon - we still
have a lot of users with libc5 compiled netscapes, wordperfects and other...
And we should support them etc etc.

> I don't see the point in renaming them.
> IMHO, this is more trouble than it worth.

This is a valid point :)

> For xpm4g-dev -> libxpm-dev, since it is possible that the user
> will not have any package which depends on xpm4g-dev, how will you ensure
> that the user will install the new package? Will you create an ugly dummy
> package or will you force the user to read the release notes again?

Yes, that is a problem. But we should rely on apt to implement the
ideal replacement as you described above.

> I want the release notes to be ideally an empty document.
> The packaging system should ideally care of everything.
> This is my release goal for potato.

Worthy idea.

Hm, after all, I realize it is too much trouble. I'll revert to
old names. I'll fix bugs, merge xpm-bin into xpm4g-dev, and ask
for removal of xpm4-altdev if noone steps forward with big need
for it in the next few days.

enJoy -*/\*- http://jagor.srce.hr/~jrodin/

Reply to: