On 9/2/17 11:02 pm, Steve Wills wrote:
Hi Julian,
On 02/07/2017 13:03, Julian Elischer wrote:
[...]
I found this all confusing and vague, but it sounds like what's
happening is you need older versions of some software for whatever
reason and to provide that you are pulling older versions of ports into
a newer ports tree. Is that right?
the problem is that the internal APIs of ports are changing too much.
Sorry, what do you mean? Can you define "too much" change?
the specification of what you are getting is intermixed too much with
the makefile components that
interact with the .mk files.
In a slightly theoretical world you would have two files..
one says "MAJOR=2 ; MINOR=2" (or similar) , and specifies the
checksums etc
and the other gives options and dependencies (which don't usually
change as fast as you think) but uses all the
complicted USES stuff for example.
so you couth PROBABLY get a range of module versions to compile with
the same base makefile as long as it matches the .mk
files.
If you are going to change the API, then you need to be able to declare
the version separately, maybe in a version/distinfo file that can be
pulled in separately at a different rev, rather than having it built
into the main Makefile of each port. Maybe the Makefile specifies a
revision range it can be used with, but that would make a huge
improvement right there.
The idea of having ports/packages support a version range for
dependencies is an interesting one, but I'm not sure how that would work.
You can not just slide one port up by 3 months, and another down by 3
months to get the revs one needs because the damned Mk files have
changed. If I coudl leave the bulk of the Makefile alone and just slide
the 'distingo/rev' file, (or be able to select a rev from one htat gives
many alternatives, that woudl be "wonderful".
You're better off finding the tree that has the right version of the
oldest thing you need to use and then updating the things that you need
updated.
but that is not reproducible in source control
Please, ports framework people, think about how this can be done, If I
have to edit a file, the game is lost.
Can we please get some understanding from ports people that they are
making things REALLY HARD on vendors and it really strengthens the hands
of the "ditch FreeBSD and go to Linux" crowd when I need to spend a
whole week trying to integrate in a set of 5 new ports into the product.
The call "It just works under linux, select the versions you want of
each package and type make" is often heard around the company. And
management is not totally deaf.
If you want to see how its' done better (still not perfect), go build a
busybox system. you can effectively select any version of any tool and
they all communicate via the pkgconf mechanism and you get the result
you want.(mostly). And the API is stable.
Sounds like you've got a lot of folks who are used to the "LTS" mindset
where they never have to update their software to work with newer
versions. But ports is a rolling release in the head branch and
quarterly for those branches, and that's how it is going to be unless
someone wants to volunteer to maintain branches for longer. The LTS
thing works because people are paid to back port fixes and you can get
those for free.
Commercial products are Hardly EVER rolling releases.
they lurch from point of stability to point of stability, with large
amounts of testing between releases.
On the pkg side of things we need the ability for pkg to say "yeah I
know I'm looking for foo-1.2.3.txz as a perfect match, but I've been
given some slack on the third digit and I can see a foo-1.2.1.txz, so
I'll install that instead".
I'm not sure how you would do that in a general way that didn't add
extra work for package maintainers.
pkg would have to do it looking in the pkg index.
Otherwise we just have to spend WAY too much time generating dozens of
"matching sets" of packages , that must be kept around forever if just
one machine shipped with that set, not to mention the fact that making
the matching set is often a real task.
Packages should generally be maintained as sets, rather than individual
packages, IMHO.
See "required by different teams" in the first email.
The way to get around the problem above CAN be (not always) to install
foo.1.2.1 first and THEN install the package you actually want, and pkg
will accept it. The problem comes when pkg needs to install a dependency
itself. Then it becomes "super picky", when there is actually a range of
package revisions that would do. Instead of letting pkg install what it
needs, we need to manually set up scripts to install the dependencies.
so that all the work done by pkg is wasted.
Please think about these two issues..
You can always use 'pkg lock' to lock a particular version of a package.
Steve
solution by sledgehammer
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
