Re: [CFT] UNIQUENAME patches
On 17/06/2012 21:11, Mel Flynn wrote:
I really don't see what the problem is with setting uniquename to:
${PORTORIGIN:S,/,__,}+${CHILDPORTNAME}
or:
databases/mysql55+server
databases/mysql55+client
etc.
And so you want to forbid + as a character for PORTNAME? So you would need
to
fix all the ports having a + in the name.
No. Ports all have a version starting with a minus sign, yet we have
ports with a minus sign in it. This is the same principle. The plus or
whatever char you pick, should be the first one from the right side
after the version part. What's in between the plus and the start of
version is subpackage/childport name.
Deciding what character or characters to use to distinguish the sub-port
part of the package name from the rest is a particularly bikeshedable
point. Virtually any of the punctuation on the keyboard could be used,
and it really won't make much difference in the end what gets chosen.
Personally I feel it should be the sole choice of the people that do the
work to implement sub-ports.
On the point of how UNIQUENAME should be defined, your arguments have
some merit, but I'm not convinced. On balance, after considering such
points I preferred what I came up with (but then I would say that,
wouldn't I?)
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
Re: [CFT] UNIQUENAME patches
On 16-6-2012 17:11, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 05:06:36PM +0200, Mel Flynn wrote:
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its
origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
Before saying that you should have a look at what pkgng is. pkgng doesn't
give a
shit about index. and changing the INDEX won't solve that if you have no way
unique way to identify a package you are doomed, have a look at every single
package management system in the world, all of the sane one with real binary
management system have a unique way to identify packages. We don't !
And you won't with this patch. Guess I should've explained myself
better. Here's your worst case scenario:
www/apache3 hits the ports tree. There's a typo in the UNIQUENAME making
it equal to apache2's uniquename. pkgng now happily concludes that
www/apache2 moved it's origin and end users get upgraded to apache3. If
you think people bitch about their lost option settings, see how happy
they are when this happens.
The point isn't the INDEX, the point is that if the information you need
isn't available, you fetch it. If you can't count on /usr/ports/MOVED
being available locally, then make it available on the package server
and fetch it. If it doesn't have the information you need, then change
the format.
Also, we *do* have a unique identifier for a package. It's enforced by
the filesystem. This doesn't change with the childports. Each child port
only applies to one port origin. So the combination of PORTORIGIN +
CHILDPORTNAME is UNIQUE!
What this patch does, is a classic example of patching the patch instead
of fixing the problem. If you're going to base critical operations on
the base that something is unique, then you /have/ to ensure that it is
unique by design, not by human intervention.
Also, there's a discussion going on at hackers about the lack of
resources for the project. And here we are: the proposed fix requires
people to check up on other people and devoting computing time to
automate some of that process.
I really don't see what the problem is with setting uniquename to:
${PORTORIGIN:S,/,__,}+${CHILDPORTNAME}
or:
databases/mysql55+server
databases/mysql55+client
etc.
Or using a GUID that is checked against a masterlist and assigned
automatically on port creation if you wish to be able to track a port's
movement through the tree.
So, my problem with this patch is that it doesn't address the issue, it
temporarily masks the issue at the advantage that users don't get option
boxes they've already filled out. Matt's work notwithstanding, it
shouldn't be the final solution to the problem.
--
Mel
___
freebsd-ports@freebsd.org mailing list
Re: [CFT] UNIQUENAME patches
On Sun, Jun 17, 2012 at 08:27:33PM +0200, Mel Flynn wrote:
On 16-6-2012 17:11, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 05:06:36PM +0200, Mel Flynn wrote:
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category
automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its
origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
Before saying that you should have a look at what pkgng is. pkgng doesn't
give a
shit about index. and changing the INDEX won't solve that if you have no way
unique way to identify a package you are doomed, have a look at every single
package management system in the world, all of the sane one with real binary
management system have a unique way to identify packages. We don't !
And you won't with this patch. Guess I should've explained myself
better. Here's your worst case scenario:
www/apache3 hits the ports tree. There's a typo in the UNIQUENAME making
it equal to apache2's uniquename. pkgng now happily concludes that
www/apache2 moved it's origin and end users get upgraded to apache3. If
you think people bitch about their lost option settings, see how happy
they are when this happens.
The maintainer should avoid that before committing. No system can prevent bugs
The point isn't the INDEX, the point is that if the information you need
isn't available, you fetch it. If you can't count on /usr/ports/MOVED
being available locally, then make it available on the package server
and fetch it. If it doesn't have the information you need, then change
the format.
Also, we *do* have a unique identifier for a package. It's enforced by
the filesystem. This doesn't change with the childports. Each child port
only applies to one port origin. So the combination of PORTORIGIN +
CHILDPORTNAME is UNIQUE!
What this patch does, is a classic example of patching the patch instead
of fixing the problem. If you're going to base critical operations on
the base that something is unique, then you /have/ to ensure that it is
unique by design, not by human intervention.
Also, there's a discussion going on at hackers about the lack of
resources for the project. And here we are: the proposed fix requires
people to check up on other people and devoting computing time to
automate some of that process.
I really don't see what the problem is with setting uniquename to:
${PORTORIGIN:S,/,__,}+${CHILDPORTNAME}
or:
databases/mysql55+server
databases/mysql55+client
etc.
And so you want to forbid + as a character for PORTNAME? So you would need to
fix all the ports having a + in the name.
Or using a GUID that is checked against a masterlist and assigned
automatically on port creation if you wish to be able to track a port's
movement through
Re: [CFT] UNIQUENAME patches
On 17-6-2012 21:51, Baptiste Daroussin wrote:
On Sun, Jun 17, 2012 at 08:27:33PM +0200, Mel Flynn wrote:
On 16-6-2012 17:11, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 05:06:36PM +0200, Mel Flynn wrote:
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category
automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its
origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
Before saying that you should have a look at what pkgng is. pkgng doesn't
give a
shit about index. and changing the INDEX won't solve that if you have no way
unique way to identify a package you are doomed, have a look at every single
package management system in the world, all of the sane one with real binary
management system have a unique way to identify packages. We don't !
And you won't with this patch. Guess I should've explained myself
better. Here's your worst case scenario:
www/apache3 hits the ports tree. There's a typo in the UNIQUENAME making
it equal to apache2's uniquename. pkgng now happily concludes that
www/apache2 moved it's origin and end users get upgraded to apache3. If
you think people bitch about their lost option settings, see how happy
they are when this happens.
The maintainer should avoid that before committing. No system can prevent bugs
The point isn't the INDEX, the point is that if the information you need
isn't available, you fetch it. If you can't count on /usr/ports/MOVED
being available locally, then make it available on the package server
and fetch it. If it doesn't have the information you need, then change
the format.
Also, we *do* have a unique identifier for a package. It's enforced by
the filesystem. This doesn't change with the childports. Each child port
only applies to one port origin. So the combination of PORTORIGIN +
CHILDPORTNAME is UNIQUE!
What this patch does, is a classic example of patching the patch instead
of fixing the problem. If you're going to base critical operations on
the base that something is unique, then you /have/ to ensure that it is
unique by design, not by human intervention.
Also, there's a discussion going on at hackers about the lack of
resources for the project. And here we are: the proposed fix requires
people to check up on other people and devoting computing time to
automate some of that process.
I really don't see what the problem is with setting uniquename to:
${PORTORIGIN:S,/,__,}+${CHILDPORTNAME}
or:
databases/mysql55+server
databases/mysql55+client
etc.
And so you want to forbid + as a character for PORTNAME? So you would need to
fix all the ports having a + in the name.
No. Ports all have a version starting with a minus sign, yet we have
ports with a minus sign in it. This is the same principle. The plus or
whatever char you pick, should be the first one
Re: [CFT] UNIQUENAME patches
On 13 June 2012 16:21, Matthew Seaman matt...@freebsd.org wrote:
Dear all,
After recent mention in this list that UNIQUENAME is not actually a
unique name for each port and how obviously non-sensical that is, plus
how it causes various problems with OPTIONS processing and how having a
proper UNIQUENAME will facilitate the new sub-package functionality
currently on the drawing board.
So, here are some patches:
http://people.freebsd.org/~matthew/uniquename/uniquenames.diff
There's also some data on the effect these have on OPTIONSFILE and
UNIQUENAME values per port in
http://people.freebsd.org/~matthew/uniquename/before/*
http://people.freebsd.org/~matthew/uniquename/after/*
Summarizing the changes:
* UNIQUENAME is now unique per port, and is primarily derived from
the port directory name.
* Where the port directory name isn't unique (eg. accessibility/orca
vs graphics/orca) there is a new UNIQUEPREFIX variable to
distinguish the affected ports. This is set for all the LANG
specific category ports (arabic, chinese, french, german, hebrew,
hungarian, japanese, korean, polish, portuguese, russian,
ukranian, vietnamese) to the standard 2 character abbreviation for
that LANG. Otherwise it is only set for the specific ports where
there is a directory name collision, usually based on the category
names.
* To avoid accidental non-uniqueness, UNIQUENAME should be treated
as a read-only variable by port maintainers. UNIQUEPREFIX should
only be set where necessary to resolve conflicts. All instances of
ports setting UNIQUENAME have been removed: in the majority of
cases, this turned out to be a no-op as the new UNIQUENAME turned
out to be the same as what most ports were previously overriding
it to.
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Chris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] UNIQUENAME patches
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
Re: [CFT] UNIQUENAME patches
On 16 June 2012 15:13, Matthew Seaman matt...@freebsd.org wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Very thoughtful, OK. You'll also need some sort of cronjob then to
yell at people who duplicate UNIQUENAME then, rather like erwin's
LATEST_LINK script; ports/Tools/scripts/check-latest-link.
Chris
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] UNIQUENAME patches
On 16-6-2012 15:18, Chris Rees wrote:
On 13 June 2012 16:21, Matthew Seaman matt...@freebsd.org wrote:
Dear all,
After recent mention in this list that UNIQUENAME is not actually a
unique name for each port and how obviously non-sensical that is, plus
how it causes various problems with OPTIONS processing and how having a
proper UNIQUENAME will facilitate the new sub-package functionality
currently on the drawing board.
So, here are some patches:
http://people.freebsd.org/~matthew/uniquename/uniquenames.diff
There's also some data on the effect these have on OPTIONSFILE and
UNIQUENAME values per port in
http://people.freebsd.org/~matthew/uniquename/before/*
http://people.freebsd.org/~matthew/uniquename/after/*
Summarizing the changes:
* UNIQUENAME is now unique per port, and is primarily derived from
the port directory name.
* Where the port directory name isn't unique (eg. accessibility/orca
vs graphics/orca) there is a new UNIQUEPREFIX variable to
distinguish the affected ports. This is set for all the LANG
specific category ports (arabic, chinese, french, german, hebrew,
hungarian, japanese, korean, polish, portuguese, russian,
ukranian, vietnamese) to the standard 2 character abbreviation for
that LANG. Otherwise it is only set for the specific ports where
there is a directory name collision, usually based on the category
names.
* To avoid accidental non-uniqueness, UNIQUENAME should be treated
as a read-only variable by port maintainers. UNIQUEPREFIX should
only be set where necessary to resolve conflicts. All instances of
ports setting UNIQUENAME have been removed: in the majority of
cases, this turned out to be a no-op as the new UNIQUENAME turned
out to be the same as what most ports were previously overriding
it to.
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
I'm also for getting rid of the badly chosen default. Since origins are
unique within the tree, we can simply use:
UNIQUENAME=${PORTORIGIN:S,/,,}
Then once you get childports (tis the new and improved name for
subpackages) you can tack that on there in the same way.
On 16-6-2012 16:13, Matthew Seaman wrote:
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
This causes exactly the problem you're trying to solve. When ports get
moved to a new location, they are for all intents and purposes new ports.
Using an origin-based UNIQUENAME makes the most sense and does the right
thing for the common case.
The issue here is that pkgng has problems with the MOVED format and
wishes to tack on to UNIQUENAME to solve it's problem. The obvious
solution here is to come up with a better MOVED format. Although, to me
it isn't clear what the problem is. I doubt it's the MOVED file, it's
probably more to do with ports that change their name based on dependency.
If you really want to track a port even if it's changing locations, then
you really should use some kind of GUID and provide a query interface
for the set options -- which we already have.
You could probably generate the GUIDs on port creation with an svn hook.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory.
If you change the default and ensure it is unique by design, then
migrating options for the user isn't that hard:
OLDSCHEME=${PKGNAMEPREFIX}${PORTNAME}
OLDOPTIONSFILE=${PORT_DBDIR}/${OLDSCHEME}/options
.if exists(${OLDOPTIONSFILE})
_CONFIG_SEQ=migrate-config ${CONFIG_SEQ}
.endif
migrate-config:
@${ECHO_CMD} An options file has been found using the old
@${ECHO_CMD} naming scheme. Would you like to migrate these
@${ECHO_CMD} settings?
...etc
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
I doubt UNIQUENAME is used in casual end user to maintainer
conversations. :)
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] UNIQUENAME patches
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its origin
and thus can't survive automatically from a move, because origin changes.
Having a uniquename able to survive from move can help a lot avoiding complex
detection of move and keeping tracking easily the package.
What could be added is a UNIQUENAMESUFFIX to be able to have a finer grain name.
regards,
Bapt
pgp8xVJcBcDZF.pgp
Description: PGP signature
Re: [CFT] UNIQUENAME patches
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] UNIQUENAME patches
On 16/06/2012 15:26, Chris Rees wrote:
On 16 June 2012 15:13, Matthew Seaman matt...@freebsd.org wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Very thoughtful, OK. You'll also need some sort of cronjob then to
yell at people who duplicate UNIQUENAME then, rather like erwin's
LATEST_LINK script; ports/Tools/scripts/check-latest-link.
http://people.freebsd.org/~matthew/uniquename/uniquecheck
needs to grow the capability to send e-mails.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature
Re: [CFT] UNIQUENAME patches
On Sat, Jun 16, 2012 at 05:06:36PM +0200, Mel Flynn wrote:
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its
origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
Before saying that you should have a look at what pkgng is. pkgng doesn't give a
shit about index. and changing the INDEX won't solve that if you have no way
unique way to identify a package you are doomed, have a look at every single
package management system in the world, all of the sane one with real binary
management system have a unique way to identify packages. We don't !
Bapt
pgpElXyexDmBE.pgp
Description: PGP signature
Re: [CFT] UNIQUENAME patches
On Sat, Jun 16, 2012 at 05:11:25PM +0200, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 05:06:36PM +0200, Mel Flynn wrote:
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category
automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its
origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
Before saying that you should have a look at what pkgng is. pkgng doesn't
give a
shit about index. and changing the INDEX won't solve that if you have no way
unique way to identify a package you are doomed, have a look at every single
package management system in the world, all of the sane one with real binary
management system have a unique way to identify packages. We don't !
Bapt
Forgot to say that origin is a good way to identify a package until we will have
sub packages (which we really need)
sub package will mean N packages will have the same origin. that way origin will
not become unique anymore.
regards,
Bapt
pgpbvWRtap6m5.pgp
Description: PGP signature
Re: [CFT] UNIQUENAME patches
On 16/06/2012 15:53, Baptiste Daroussin wrote: What could be added is a UNIQUENAMESUFFIX to be able to have a finer grain name. That's certainly possible, but I was thinking about your plans to create sub-packages. As I understand it, you'll be building and installing each port into a staging area, and then creating a number of different packages from what's in the staging area. So for a port foo, you might create: foo-0.99 --- the foo application and libfoo.so.0 shared library foo-docs-0.99 --- documentation foo-examples-0.99 --- example configurations etc. foo-devlibs-0.99 --- *.h headers, libfoo.a static lib, profiling libs and other things useful for developers. and so forth. So these are distinct packages all from one port with its own UNIQUENAME and hence all using that port's OPTIONS settings, and all built in one block. Having UNIQUENAMESUFFIX for docs, examples, devlibs etc. would imply all of those are entirely separate ports, like the way bacula and bacula-docs are handled at the moment. I can see there will need to be some sort of SUBPACKAGESUFFIXES variable and associated gubbins in the ports makefiles, to do that, plus something like tagging the entries in pkg-plist to identify which sub-package they should belong to. Trying to mix that with UNIQUENAMESUFFIXes would get pretty complicated. Not to mention the question of foo-devel -- is that the devel sub-package of the foo port, or a separate foo-devel port?[*] Cheers, Matthew [*] Hmmm... maybe sub-packages suffixes should use a different separator: foo-0.99, foo--docs-0.99, foo--examples-0.99 foo--devlibs-0.99 (?) -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: [CFT] UNIQUENAME patches
On Sat, Jun 16, 2012 at 04:49:22PM +0100, Matthew Seaman wrote: On 16/06/2012 15:53, Baptiste Daroussin wrote: What could be added is a UNIQUENAMESUFFIX to be able to have a finer grain name. That's certainly possible, but I was thinking about your plans to create sub-packages. As I understand it, you'll be building and installing each port into a staging area, and then creating a number of different packages from what's in the staging area. So for a port foo, you might create: foo-0.99 --- the foo application and libfoo.so.0 shared library foo-docs-0.99 --- documentation foo-examples-0.99 --- example configurations etc. foo-devlibs-0.99 --- *.h headers, libfoo.a static lib, profiling libs and other things useful for developers. and so forth. So these are distinct packages all from one port with its own UNIQUENAME and hence all using that port's OPTIONS settings, and all built in one block. Having UNIQUENAMESUFFIX for docs, examples, devlibs etc. would imply all of those are entirely separate ports, like the way bacula and bacula-docs are handled at the moment. I can see there will need to be some sort of SUBPACKAGESUFFIXES variable and associated gubbins in the ports makefiles, to do that, plus something like tagging the entries in pkg-plist to identify which sub-package they should belong to. Trying to mix that with UNIQUENAMESUFFIXes would get pretty complicated. Not to mention the question of foo-devel -- is that the devel sub-package of the foo port, or a separate foo-devel port?[*] Yes you are right regards, Bapt pgp4SeyYjhbcS.pgp Description: PGP signature
Re: [CFT] UNIQUENAME patches
On 2012-06-16 17:49, Matthew Seaman wrote: On 16/06/2012 15:53, Baptiste Daroussin wrote: What could be added is a UNIQUENAMESUFFIX to be able to have a finer grain name. That's certainly possible, but I was thinking about your plans to create sub-packages. As I understand it, you'll be building and installing each port into a staging area, and then creating a number of different packages from what's in the staging area. So for a port foo, you might create: foo-0.99 --- the foo application and libfoo.so.0 shared library foo-docs-0.99 --- documentation foo-examples-0.99 --- example configurations etc. foo-devlibs-0.99 --- *.h headers, libfoo.a static lib, profiling libs and other things useful for developers. and so forth. So these are distinct packages all from one port with its own UNIQUENAME and hence all using that port's OPTIONS settings, and all built in one block. Having UNIQUENAMESUFFIX for docs, examples, devlibs etc. would imply all of those are entirely separate ports, like the way bacula and bacula-docs are handled at the moment. This looks like most RPM packages are build but with one major difference With one RPM spec file you can build foo, foo-docs, foo-devlibs and foo-examples in one build and get 4 rpm's in one run. With the ports infrastructure we have to run several builds one for foo, one for foo-devlibs and maybe one for foo-docs if docs are generated. Here we can take bacula, pgsql or mysql as example. To build the server and the client the build is done twice and only different files are taken to crate the package. Unless the ports infrastructure can build several packages from one port in one run this looks for me very impractical and time consuming. Also DEPENDENCY handling can become a real mess if a port needs foo, foo-devlibs , bar, bar-devlibs ... to build. Even this writeup looks critical I think I like the idea to split the packages if pkg has also the ability to search for packages like 'yum search' or apt .. I always smiled if I read Linux $fillInDistro has x thousands packages and if you look seriously divide the amount by 3 or 4 to get a real number. I suspect FreeBSD will be hit easily 50.000 packages with this split. How much additional time will take to do a full portstree build ?? I can see there will need to be some sort of SUBPACKAGESUFFIXES variable and associated gubbins in the ports makefiles, to do that, plus something like tagging the entries in pkg-plist to identify which sub-package they should belong to. Trying to mix that with UNIQUENAMESUFFIXes would get pretty complicated. Not to mention the question of foo-devel -- is that the devel sub-package of the foo port, or a separate foo-devel port?[*] [*] Hmmm... maybe sub-packages suffixes should use a different separator: foo-0.99, foo--docs-0.99, foo--examples-0.99 foo--devlibs-0.99 (?) Looks silly but you have more then the '-' (_ + %) for example foo+docs, foo__docs, foo%docs -- Regards, olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] UNIQUENAME patches
On 16/06/2012 20:11, Olli Hauer wrote: With one RPM spec file you can build foo, foo-docs, foo-devlibs and foo-examples in one build and get 4 rpm's in one run. With the ports infrastructure we have to run several builds one for foo, one for foo-devlibs and maybe one for foo-docs if docs are generated. Exactly -- that's precisely the functionality that sub-packages is going to introduce for the ports. You do one build stage, and can then split up the results into several different packages. One port, several pkgs. This will require the use of a staging directory, so you can package up a port without having to have it installed. Staging is another new feature currently on the drawing board. Also DEPENDENCY handling can become a real mess if a port needs foo, foo-devlibs , bar, bar-devlibs ... to build. Well, maybe. For an end-user system where you install from pkgs (in this case, meaning pkgng -- that's the driver for most of these new features ) you only really need the base 'foo-0.99' package: dependencies will be pretty much equivalent to what there is now. Optionall you'll probably want foo--docs and foo--examples too, but you don't have to have them if installing a really stripped down system. There will probably be some sort of global setting to say automatically install docs and/or examples when you install the primary port. When you're doing pkg building, then yes, you'ld need to install a bunch more pkgs -- they'd be BUILD_DEPENDS rather than RUN_DEPENDS -- but the ports infrastructure should take care of that. Using a package builder like poudriere to maintain your own pkg repo should become standard procedure for supporting any reasonably sized installation, and that will gloss over all the boring detail of that for you. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: [CFT] UNIQUENAME patches
On 2012-06-16 22:36, Matthew Seaman wrote: On 16/06/2012 20:11, Olli Hauer wrote: With one RPM spec file you can build foo, foo-docs, foo-devlibs and foo-examples in one build and get 4 rpm's in one run. With the ports infrastructure we have to run several builds one for foo, one for foo-devlibs and maybe one for foo-docs if docs are generated. Exactly -- that's precisely the functionality that sub-packages is going to introduce for the ports. You do one build stage, and can then split up the results into several different packages. One port, several pkgs. sounds good This will require the use of a staging directory, so you can package up a port without having to have it installed. Staging is another new feature currently on the drawing board. Also DEPENDENCY handling can become a real mess if a port needs foo, foo-devlibs , bar, bar-devlibs ... to build. Well, maybe. For an end-user system where you install from pkgs (in this case, meaning pkgng -- that's the driver for most of these new features ) you only really need the base 'foo-0.99' package: dependencies will be pretty much equivalent to what there is now. Optionall you'll probably want foo--docs and foo--examples too, but you don't have to have them if installing a really stripped down system. There will probably be some sort of global setting to say automatically install docs and/or examples when you install the primary port. When you're doing pkg building, then yes, you'ld need to install a bunch more pkgs -- they'd be BUILD_DEPENDS rather than RUN_DEPENDS -- but the ports infrastructure should take care of that. Using a package builder like poudriere to maintain your own pkg repo should become standard procedure for supporting any reasonably sized installation, and that will gloss over all the boring detail of that for you. also sounds good to me, at the moment I stopped testing pkgng since I use exclusive tinderbox with several builds for prod machines and haven't had the time to look deeper into the ./tb tbcleanup bug (tb head) which wiped twice a view builds from two different build machines. http://www.marcuscom.com/pipermail/tinderbox-list/2012-May/002601.html -- Regards, olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] UNIQUENAME patches
On Fri, Jun 15, 2012 at 08:43:59AM +0100, Matthew Seaman wrote:
On 15/06/2012 00:06, Jason Helfman wrote:
On Thu, Jun 14, 2012 at 10:14:52AM +0200, Baptiste Daroussin thus spake:
On Wed, Jun 13, 2012 at 04:21:16PM +0100, Matthew Seaman wrote:
Dear all,
After recent mention in this list that UNIQUENAME is not actually a
unique name for each port and how obviously non-sensical that is, plus
how it causes various problems with OPTIONS processing and how having a
proper UNIQUENAME will facilitate the new sub-package functionality
currently on the drawing board.
So, here are some patches:
http://people.freebsd.org/~matthew/uniquename/uniquenames.diff
There's also some data on the effect these have on OPTIONSFILE and
UNIQUENAME values per port in
http://people.freebsd.org/~matthew/uniquename/before/*
http://people.freebsd.org/~matthew/uniquename/after/*
Summarizing the changes:
* UNIQUENAME is now unique per port, and is primarily derived from
the port directory name.
* Where the port directory name isn't unique (eg. accessibility/orca
vs graphics/orca) there is a new UNIQUEPREFIX variable to
distinguish the affected ports. This is set for all the LANG
specific category ports (arabic, chinese, french, german, hebrew,
hungarian, japanese, korean, polish, portuguese, russian,
ukranian, vietnamese) to the standard 2 character abbreviation for
that LANG. Otherwise it is only set for the specific ports where
there is a directory name collision, usually based on the category
names.
* To avoid accidental non-uniqueness, UNIQUENAME should be treated
as a read-only variable by port maintainers. UNIQUEPREFIX should
only be set where necessary to resolve conflicts. All instances of
ports setting UNIQUENAME have been removed: in the majority of
cases, this turned out to be a no-op as the new UNIQUENAME turned
out to be the same as what most ports were previously overriding
it to.
* The way UNIQUENAME is defined means that it doesn't now change
depending on the version of python, ruby or apache installed on a
machine.
* UNIQUENAME will have changed for numerous ports -- consequently
port OPTIONFILEs may well have changed location. By default now,
each port should have an individual OPTIONFILE location. This
has removed a number of accidental cases of different (maybe
completely unrelated) ports sharing the same OPTIONSFILE.
* If you do want to share the same OPTIONSFILE between several
different ports, you can modify OPTIONSFILE directly or there is
now a new OPTIONS_DIR variable allowing a simple way for you to
override the location: OPTIONSFILE is redefined as:
OPTIONSFILE= ${PORT_DBDIR}/${OPTIONS_DIR}/options
with OPTIONS_DIR defaulting (as before) to UNIQUENAME unless
overriden. See databases/postgresql91-server for an example.
* Other things that may be affected: ports with USE_LDCONFIG or
USE_LDCONFIG32 can have ldconfig data written to a different
location. This shouldn't make any user-visible change.
Per-port options settings (OPTIONSng-style) in /etc/make.conf
may need to be modified.
Please test. Comments, corrections and bug reports will be most welcome.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
Thank you very much for the patch, it solves a problem that sticks for way
too
long in the ports tree: the problem with options files.
It also solve another problem which is really important when dealing with
binary
packages and will allow to simplify the life of pkgng development: we
would for
real get a unique identifier for a package!!!, before for we were
workarounding
the problem considering origin as our unique identifier which worked but
no
that good, it was hard to track a package which was moved (no MOVED isn't
an
ideal solution to track them in full binary world)
The other thing that it could solve for binary only world if that if
people from
python ruby perl and others uses always the same uniquename for their
default
version, then it will be easy to move from python26 as a default to
python27 as
a default in full binary environment with no manual intervention from the
user
and no complex hacks to figure it out in the package tool.
Last but no least once it is done the LATEST_LINK overwrite could die, and
the
feature associated could just use LATEST_LINK.
Please do test this patch comment on it and improve it.
regards,
Bapt
Great patch. I've done some testing, but was aware of this issue, and even
have raised this with bapt during his implementation of optionsng to see if
he knew of this issue.
Re: [CFT] UNIQUENAME patches
On Wed, Jun 13, 2012 at 04:21:16PM +0100, Matthew Seaman wrote:
Dear all,
After recent mention in this list that UNIQUENAME is not actually a
unique name for each port and how obviously non-sensical that is, plus
how it causes various problems with OPTIONS processing and how having a
proper UNIQUENAME will facilitate the new sub-package functionality
currently on the drawing board.
So, here are some patches:
http://people.freebsd.org/~matthew/uniquename/uniquenames.diff
There's also some data on the effect these have on OPTIONSFILE and
UNIQUENAME values per port in
http://people.freebsd.org/~matthew/uniquename/before/*
http://people.freebsd.org/~matthew/uniquename/after/*
Summarizing the changes:
* UNIQUENAME is now unique per port, and is primarily derived from
the port directory name.
* Where the port directory name isn't unique (eg. accessibility/orca
vs graphics/orca) there is a new UNIQUEPREFIX variable to
distinguish the affected ports. This is set for all the LANG
specific category ports (arabic, chinese, french, german, hebrew,
hungarian, japanese, korean, polish, portuguese, russian,
ukranian, vietnamese) to the standard 2 character abbreviation for
that LANG. Otherwise it is only set for the specific ports where
there is a directory name collision, usually based on the category
names.
* To avoid accidental non-uniqueness, UNIQUENAME should be treated
as a read-only variable by port maintainers. UNIQUEPREFIX should
only be set where necessary to resolve conflicts. All instances of
ports setting UNIQUENAME have been removed: in the majority of
cases, this turned out to be a no-op as the new UNIQUENAME turned
out to be the same as what most ports were previously overriding
it to.
* The way UNIQUENAME is defined means that it doesn't now change
depending on the version of python, ruby or apache installed on a
machine.
* UNIQUENAME will have changed for numerous ports -- consequently
port OPTIONFILEs may well have changed location. By default now,
each port should have an individual OPTIONFILE location. This
has removed a number of accidental cases of different (maybe
completely unrelated) ports sharing the same OPTIONSFILE.
* If you do want to share the same OPTIONSFILE between several
different ports, you can modify OPTIONSFILE directly or there is
now a new OPTIONS_DIR variable allowing a simple way for you to
override the location: OPTIONSFILE is redefined as:
OPTIONSFILE= ${PORT_DBDIR}/${OPTIONS_DIR}/options
with OPTIONS_DIR defaulting (as before) to UNIQUENAME unless
overriden. See databases/postgresql91-server for an example.
* Other things that may be affected: ports with USE_LDCONFIG or
USE_LDCONFIG32 can have ldconfig data written to a different
location. This shouldn't make any user-visible change.
Per-port options settings (OPTIONSng-style) in /etc/make.conf
may need to be modified.
Please test. Comments, corrections and bug reports will be most welcome.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
Thank you very much for the patch, it solves a problem that sticks for way too
long in the ports tree: the problem with options files.
It also solve another problem which is really important when dealing with binary
packages and will allow to simplify the life of pkgng development: we would for
real get a unique identifier for a package!!!, before for we were workarounding
the problem considering origin as our unique identifier which worked but no
that good, it was hard to track a package which was moved (no MOVED isn't an
ideal solution to track them in full binary world)
The other thing that it could solve for binary only world if that if people from
python ruby perl and others uses always the same uniquename for their default
version, then it will be easy to move from python26 as a default to python27 as
a default in full binary environment with no manual intervention from the user
and no complex hacks to figure it out in the package tool.
Last but no least once it is done the LATEST_LINK overwrite could die, and the
feature associated could just use LATEST_LINK.
Please do test this patch comment on it and improve it.
regards,
Bapt
pgpWyWRLAcZp0.pgp
Description: PGP signature
Re: [CFT] UNIQUENAME patches
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Jun 14, 2012 at 10:14:52AM +0200, Baptiste Daroussin thus spake:
On Wed, Jun 13, 2012 at 04:21:16PM +0100, Matthew Seaman wrote:
Dear all,
After recent mention in this list that UNIQUENAME is not actually a
unique name for each port and how obviously non-sensical that is, plus
how it causes various problems with OPTIONS processing and how having a
proper UNIQUENAME will facilitate the new sub-package functionality
currently on the drawing board.
So, here are some patches:
http://people.freebsd.org/~matthew/uniquename/uniquenames.diff
There's also some data on the effect these have on OPTIONSFILE and
UNIQUENAME values per port in
http://people.freebsd.org/~matthew/uniquename/before/*
http://people.freebsd.org/~matthew/uniquename/after/*
Summarizing the changes:
* UNIQUENAME is now unique per port, and is primarily derived from
the port directory name.
* Where the port directory name isn't unique (eg. accessibility/orca
vs graphics/orca) there is a new UNIQUEPREFIX variable to
distinguish the affected ports. This is set for all the LANG
specific category ports (arabic, chinese, french, german, hebrew,
hungarian, japanese, korean, polish, portuguese, russian,
ukranian, vietnamese) to the standard 2 character abbreviation for
that LANG. Otherwise it is only set for the specific ports where
there is a directory name collision, usually based on the category
names.
* To avoid accidental non-uniqueness, UNIQUENAME should be treated
as a read-only variable by port maintainers. UNIQUEPREFIX should
only be set where necessary to resolve conflicts. All instances of
ports setting UNIQUENAME have been removed: in the majority of
cases, this turned out to be a no-op as the new UNIQUENAME turned
out to be the same as what most ports were previously overriding
it to.
* The way UNIQUENAME is defined means that it doesn't now change
depending on the version of python, ruby or apache installed on a
machine.
* UNIQUENAME will have changed for numerous ports -- consequently
port OPTIONFILEs may well have changed location. By default now,
each port should have an individual OPTIONFILE location. This
has removed a number of accidental cases of different (maybe
completely unrelated) ports sharing the same OPTIONSFILE.
* If you do want to share the same OPTIONSFILE between several
different ports, you can modify OPTIONSFILE directly or there is
now a new OPTIONS_DIR variable allowing a simple way for you to
override the location: OPTIONSFILE is redefined as:
OPTIONSFILE= ${PORT_DBDIR}/${OPTIONS_DIR}/options
with OPTIONS_DIR defaulting (as before) to UNIQUENAME unless
overriden. See databases/postgresql91-server for an example.
* Other things that may be affected: ports with USE_LDCONFIG or
USE_LDCONFIG32 can have ldconfig data written to a different
location. This shouldn't make any user-visible change.
Per-port options settings (OPTIONSng-style) in /etc/make.conf
may need to be modified.
Please test. Comments, corrections and bug reports will be most welcome.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
Thank you very much for the patch, it solves a problem that sticks for way too
long in the ports tree: the problem with options files.
It also solve another problem which is really important when dealing with
binary
packages and will allow to simplify the life of pkgng development: we would for
real get a unique identifier for a package!!!, before for we were workarounding
the problem considering origin as our unique identifier which worked but no
that good, it was hard to track a package which was moved (no MOVED isn't an
ideal solution to track them in full binary world)
The other thing that it could solve for binary only world if that if people
from
python ruby perl and others uses always the same uniquename for their default
version, then it will be easy to move from python26 as a default to python27 as
a default in full binary environment with no manual intervention from the user
and no complex hacks to figure it out in the package tool.
Last but no least once it is done the LATEST_LINK overwrite could die, and the
feature associated could just use LATEST_LINK.
Please do test this patch comment on it and improve it.
regards,
Bapt
Great patch. I've done some testing, but was aware of this issue, and even
have raised this with bapt during his implementation of optionsng to see if
he knew of this issue.
From what I can see, this also takes care of this PR, but also adds some
needed consistency that has long been removed.
And by looking up the pr, I see you already have found it :)
