Opened 15 years ago

Closed 14 years ago

#19004 closed enhancement (duplicate)

Sticky versions?

Reported by: macports@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: base Version: 1.7.0
Keywords: Cc:
Port:

Description

Is it possible to tag a port in a way that makes "port upgrade outdated" not upgrade the port in question? This is possible with other package managing tools, such as apt.

I ask because Subversion was recently updated to version 1.6. This makes Subversion integration in Eclipse (and possibly other IDE's) fail, since it doesn't recognize Subversion 1.6's file format. I had to downgrade to 1.5 to make everything work again.

It would have been great if I could just tag my current Subversion install (1.5.5_0) as being sticky.

Change History (9)

comment:1 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

You can emulate this behavior with a local repository, but if you
are using Subclipse, it says on its web page that it now supports subversion 1.6.

comment:2 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: mcalhoun@… added

Cc Me!

comment:3 Changed 15 years ago by macports@…

I'm using Subversive since it's hosted by Eclipse, but it only supports Subversion 1.5. Anyway, I'll look at the local repository solution. It looks kinda overkill, though...

comment:4 in reply to:  3 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Replying to macports@…:

I'm using Subversive since it's hosted by Eclipse, but it only supports Subversion 1.5. Anyway, I'll look at the local repository solution. It looks kinda overkill, though...

Granted, it may not be ideal, but sticky versions are a little dangerous in and of themselves.
Portfiles maintainers rely on the fact that they know exactly how the other ports are installed (at least if the user is fully upgraded).
If you take that away with sticky versions, then maintenance becomes much harder.
I would vote against such a change.

I keep a local repository myself, so please let me know if you run into any problems.

comment:5 Changed 15 years ago by macports@…

Sticky versions works great in the apt world, I can't see why it wouldn't in the world of macports.

If I set a sticky version of v1.1 on myProgram, and yourProgram requires myProgram v1.2, apt will give you the choice of either 1) not install yourProgram or 2) upgrade myProgram.

comment:6 in reply to:  5 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Replying to macports@…:

Sticky versions works great in the apt world, I can't see why it wouldn't in the world of macports.

If I set a sticky version of v1.1 on myProgram, and yourProgram requires myProgram v1.2, apt will give you the choice of either 1) not install yourProgram or 2) upgrade myProgram.

I agree that this would be a good feature, but it requires much more work on the part of the maintainter.
It has been my experience that a number of software packages do not explicitly list their dependencies much less the minimum version required.
As it stands now, the maintainter must only make sure his/her port works with the one version installed.

If you don't buy that argument, then posting your idea to the developers mailing list (with a link back here) might get more feedback.

comment:7 Changed 15 years ago by raimue (Rainer Müller)

Component: portsbase
Milestone: MacPorts 1.7.1MacPorts Future

As you say in your apt example, this requires tracking version numbers in dependencies. MacPorts does not do this at the moment. It would be more work for maintainers to find out against which dependency versions the port works.

comment:8 Changed 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: mcalhoun@… removed

comment:9 Changed 14 years ago by jmroot (Joshua Root)

Milestone: MacPorts Future
Resolution: duplicate
Status: newclosed
Note: See TracTickets for help on using tickets.