Date: Fri, 25 Jan 2002 03:07:17 -0500 From: Tadayuki OKADA <tadayuki@mediaone.net> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: tadayuki.okada@windriver.com, mi@aldan.algebra.com, will@csociety.org, freebsd-ports@freebsd.org Subject: Re: cvs commit: ports/graphics/gd Makefile pkg-comment Message-ID: <20020125030717.62e1cf65.tadayuki@mediaone.net> In-Reply-To: <200201241908.g0OJ8Q101722@Magelan.Leidinger.net> References: <3C5022E4.4294D4F3@windriver.com> <200201241908.g0OJ8Q101722@Magelan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
OK. This will be my last try. I won't bother you again. On Thu, 24 Jan 2002 20:08:23 +0100 (CET) Alexander Leidinger <Alexander@Leidinger.net> wrote: > On 24 Jan, Tadayuki OKADA wrote: > >> It isn't common practice to bump the revision of dependand ports, see > >> below, so there isn't the need for such a tool at the moment. > > So you ignore Porter's Handbook? > > No, I don't ignore it. I just commented on the actual practice (see my > png/gnome comment). If you don't ignore it, you do bump PORTREVISION as it says, right? > >> At least I have _not_ seen a PORTREVISION bump on a lot of gnome* ports > >> at the time the library version of libpng changed (and I had to > >> recompile a lot of gnome* ports to get my custom widget background > >> back). > > You don't need to bump PORTREVISION if a port depends on a shlib > > indirectly. Assume the dependency is port A -> port B -> port C, > > then port C's shlib major version is increased, port B needs > > PORTREVISION bump, but as long as port B is binary compatible with > > the previous version, port A doesn't need PORTREVISION bump. > > I've already seen the opposide. I can't remember which port was > affected, but I had to recompile a lot of gnome ports, which didn't have > libpng in the dependency list directly (but indirectly). If what you are saying is true, we might need some investigation. Theoretically the rule I described should work. Maybe there are some ports like this: port A depends on port B and port C directly (i.e. link against libB.so and libC.so). port B depnds on port C. Forget to add LIB_DEPNDS line for port C to port A's Makefile. In this case port A should have LIB_DEPENDS line for port C. Or because of the component model? # I know nothing about ORBit or CORBA, so please don't ask me. Or something else??? > >> >> And even if we decide to increment the PORTREVISION this isn't really a > >> >> strong argument as I already explained above. > >> > pkg_version is in the base system. portversion is part of portupgrade which > >> > is very popular tool these days. > >> > We don't have any tool other than these to detect which port to upgrade. > >> > >> Sorry, I wanted to say: "If we decide to accept Mikhail's proposal, we > >> have the possibility to determine which port needs a PORTREVISION bump > >> just by looking at the dependency information." > > That's a possibility. Not the current implementation. > > The proposal is incomplete without the utility side changes. > > Sorry, but I can't see where Mikhail's proposal changes the behavior in > this regard. Can you please explain it to me? Previously you said 'we have the possibility'. It means we don't have it yet. There is no tool to detect a need of PORTREVISION bump just by the dependency. Without such tool, port A's PORTREVISON will not be bumped. It does violate Porter's Handbook. And it also breaks pkg_version and portversion's updates detection. # Those tools are written based on the assumption we observe Porter's Handbook. > >> Makhail's proposal doesn't change any run time behavior. It only changes > >> the compile time behavior if there are outdated ports installed. This > >> doesn't affect official packages. > > As I said, it breaks user side update process. > > How does a user know when package A is rebuilt with updated package B > > which bumps shlib major version and may include critical bug fixes > > without port A's PORTREVISION bump? > > The actual way is to update the port Makefile when the library version > changes, even if the port is API compatible (only the ABI of the library > changed). Yes, with PORTREVISION bump. > Mikhail's proposal changes this to: Update the port Makefile when the > API of the library changes. Yes. i.e. no PORTREVISON bump for no API change. > So this proposal is an improvement, because it breaks ports less often > and reduces the load for the ports team. And it won't complain when port A is built with old version of libB.so, despite the avalability of new port B. And there will be several packages they have exactly same name and version, but they depend on different major version of shlib. i.e. their binaries are different. How can 'Joe user' know a need of update when the latest package has exactly same version with the installed one. And one more example (how many times do I have to explain this?): package A and package B are installed. port B get shlib major version bump. install new package B. pkg_version or portversion can't detect needs of update for package A, because A's PORTREVISON is not bumped. so installed package A still depend on old version of libB.so. And new libB.so may include critical fix like security hole. Are these improvements for you? > I don't see where the run time behavior changes, only the compile time > behavior changes. If I'm wrong here, please tell me where I don't get it > right. I'm not saying it changes runtime behavior. What I'm saying is it breaks user's proper update process. > >> The proposal is only benefical for a small part of the userbase, e.g. > >> for every ports commiter who knows what he does. "Joe User", which uses > >> official packages, is not affected. > > So you don't care about ports user? > > I care about them, but I don't see where the average ports user can have > a problem. Can you please describe it to me? I'm a ports user. And I depend on pkg_version to detect updated port. His proposal breaks reliability of pkg_version. I will have a problem. > >> > Unless we have other tool to do this, we should keep ports complient with > >> > these tools. > >> > >> Mikhail's proposal doesn't break them. > > Yes, it does. > > How? Can you please give me an example? Regards, -- Tadayuki OKADA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020125030717.62e1cf65.tadayuki>