Support using the auto-detected name

[bwarden]

Rework to absorb a lot of the work we were doing in makefiles so that we
can avoid setting the package name manually in 'make autospecnew'.

[bwarden]

You'll also need to modify Makefile.toplevel to:

1. Remove the check for $(NAME)
2. Remove $(MAKE) clone_$(NAME) and the mkdir/git block
3. Don't write the Makefile (autospec will do that instead)
4. Remove the --target and --name parameters from autospec
5. Add the --package-dir packages/ param to autospec
6. Remove the else block for $(NAME) already exists...

...and add git_pull to autospec.conf if you use a different git URI for pull than push.

[bwarden]

The link-new-rpms and checkblacklist actions will also need to be modified/replaced at some point.

[bwarden]

@phmccarty, @bryteise Could I have your review, please?

[bwarden]

Remaining work, in case someone else has time to pick up the torch:

• refactor config to read autospec.conf first (so we know the git URL patterns), then go back and read package configuration files after deciding what the package name and path are.
• tackle creation of rpms subdir and hard-linking resulting RPMs. This is the last ${NAME} dependency in the common makefile.

[phmccarty]

@bryteise Is this feature still in scope for autospec?

I think it would be nice to autodetect the package name, but due to the extra complexity introduced with the interaction with the common tooling, we were somewhat undecided about what needed to change in that tooling, and autospec, or both, to accommodate...

[bryteise]

Hrm I'm a little unsure about all the bits that need to be reworked.

Because make autospecnew is probably the way an autodetected name would be made use of, getting the common tooling as much out of the way as possible of autospec doing what needs to be would be sensible. We could also we add a --get-package-name type option for autospec and then common tooling gets the name from that and reruns autospec with the full options like now under the hood.

[phmccarty]

I agree that all the name detection logic should be handled by autospec. The idea of adding a --get-package-name flag to autospec to replace the NAME value for make autospecnew also sounds reasonable...

[phmccarty]

There was also some discussion at the time about autospec creating the package Makefile (instead of the common tooling) if it doesn't exist, so that consideration could be revisited as well.

Edit: One second look, this PR adds the makefile write routine, so disregard.

Edit 2: IIRC, at the time, I wasn't convinced that autospec writing the makefile was a good idea, since the primary user of it is the common tooling, not autospec. Perhaps autospec could write a separate makefile (say, Makefile.autospec) that would be fully owned by autospec, and the common tooling could source it -- a similar approach to how it handles Makefile.custom. For non-autospec packages, Makefile would define PKG_NAME, and for autospec packages, Makefile.autospec would define it, replacing the value from Makefile if it exists there. And if autospec cannot detect, or misdetects, the package name, the common tooling could fall back to use PKG_NAME defined in Makefile (or Makefile.custom) if that's easier / makes more sense, and propagate that value to autospec like it does now.

[bwarden]

Rework to absorb a lot of the work we were doing in makefiles so that we
can avoid setting the package name manually in 'make autospecnew'.

[bwarden]

You'll also need to modify Makefile.toplevel to:

1. Remove the check for $(NAME)
2. Remove $(MAKE) clone_$(NAME) and the mkdir/git block
3. Don't write the Makefile (autospec will do that instead)
4. Remove the --target and --name parameters from autospec
5. Add the --package-dir packages/ param to autospec
6. Remove the else block for $(NAME) already exists...

...and add git_pull to autospec.conf if you use a different git URI for pull than push.

[bwarden]

The link-new-rpms and checkblacklist actions will also need to be modified/replaced at some point.

[bwarden]

@phmccarty, @bryteise Could I have your review, please?

[bwarden]

Remaining work, in case someone else has time to pick up the torch:

• refactor config to read autospec.conf first (so we know the git URL patterns), then go back and read package configuration files after deciding what the package name and path are.
• tackle creation of rpms subdir and hard-linking resulting RPMs. This is the last ${NAME} dependency in the common makefile.

[phmccarty]

@bryteise Is this feature still in scope for autospec?

I think it would be nice to autodetect the package name, but due to the extra complexity introduced with the interaction with the common tooling, we were somewhat undecided about what needed to change in that tooling, and autospec, or both, to accommodate...

[bryteise]

Hrm I'm a little unsure about all the bits that need to be reworked.

Because make autospecnew is probably the way an autodetected name would be made use of, getting the common tooling as much out of the way as possible of autospec doing what needs to be would be sensible. We could also we add a --get-package-name type option for autospec and then common tooling gets the name from that and reruns autospec with the full options like now under the hood.

[phmccarty]

I agree that all the name detection logic should be handled by autospec. The idea of adding a --get-package-name flag to autospec to replace the NAME value for make autospecnew also sounds reasonable...

[phmccarty]

There was also some discussion at the time about autospec creating the package Makefile (instead of the common tooling) if it doesn't exist, so that consideration could be revisited as well.

Edit: One second look, this PR adds the makefile write routine, so disregard.

Edit 2: IIRC, at the time, I wasn't convinced that autospec writing the makefile was a good idea, since the primary user of it is the common tooling, not autospec. Perhaps autospec could write a separate makefile (say, Makefile.autospec) that would be fully owned by autospec, and the common tooling could source it -- a similar approach to how it handles Makefile.custom. For non-autospec packages, Makefile would define PKG_NAME, and for autospec packages, Makefile.autospec would define it, replacing the value from Makefile if it exists there. And if autospec cannot detect, or misdetects, the package name, the common tooling could fall back to use PKG_NAME defined in Makefile (or Makefile.custom) if that's easier / makes more sense, and propagate that value to autospec like it does now.

[bwarden]

Rework to absorb a lot of the work we were doing in makefiles so that we
can avoid setting the package name manually in 'make autospecnew'.

[bwarden]

You'll also need to modify Makefile.toplevel to:

1. Remove the check for $(NAME)
2. Remove $(MAKE) clone_$(NAME) and the mkdir/git block
3. Don't write the Makefile (autospec will do that instead)
4. Remove the --target and --name parameters from autospec
5. Add the --package-dir packages/ param to autospec
6. Remove the else block for $(NAME) already exists...

...and add git_pull to autospec.conf if you use a different git URI for pull than push.

[bwarden]

The link-new-rpms and checkblacklist actions will also need to be modified/replaced at some point.

[bwarden]

@phmccarty, @bryteise Could I have your review, please?

[bwarden]

Remaining work, in case someone else has time to pick up the torch:

• refactor config to read autospec.conf first (so we know the git URL patterns), then go back and read package configuration files after deciding what the package name and path are.
• tackle creation of rpms subdir and hard-linking resulting RPMs. This is the last ${NAME} dependency in the common makefile.

[phmccarty]

@bryteise Is this feature still in scope for autospec?

I think it would be nice to autodetect the package name, but due to the extra complexity introduced with the interaction with the common tooling, we were somewhat undecided about what needed to change in that tooling, and autospec, or both, to accommodate...

[bryteise]

Hrm I'm a little unsure about all the bits that need to be reworked.

Because make autospecnew is probably the way an autodetected name would be made use of, getting the common tooling as much out of the way as possible of autospec doing what needs to be would be sensible. We could also we add a --get-package-name type option for autospec and then common tooling gets the name from that and reruns autospec with the full options like now under the hood.

[phmccarty]

I agree that all the name detection logic should be handled by autospec. The idea of adding a --get-package-name flag to autospec to replace the NAME value for make autospecnew also sounds reasonable...

[phmccarty]

There was also some discussion at the time about autospec creating the package Makefile (instead of the common tooling) if it doesn't exist, so that consideration could be revisited as well.

Edit: One second look, this PR adds the makefile write routine, so disregard.

Edit 2: IIRC, at the time, I wasn't convinced that autospec writing the makefile was a good idea, since the primary user of it is the common tooling, not autospec. Perhaps autospec could write a separate makefile (say, Makefile.autospec) that would be fully owned by autospec, and the common tooling could source it -- a similar approach to how it handles Makefile.custom. For non-autospec packages, Makefile would define PKG_NAME, and for autospec packages, Makefile.autospec would define it, replacing the value from Makefile if it exists there. And if autospec cannot detect, or misdetects, the package name, the common tooling could fall back to use PKG_NAME defined in Makefile (or Makefile.custom) if that's easier / makes more sense, and propagate that value to autospec like it does now.

[bwarden]

Rework to absorb a lot of the work we were doing in makefiles so that we
can avoid setting the package name manually in 'make autospecnew'.

[bwarden]

You'll also need to modify Makefile.toplevel to:

1. Remove the check for $(NAME)
2. Remove $(MAKE) clone_$(NAME) and the mkdir/git block
3. Don't write the Makefile (autospec will do that instead)
4. Remove the --target and --name parameters from autospec
5. Add the --package-dir packages/ param to autospec
6. Remove the else block for $(NAME) already exists...

...and add git_pull to autospec.conf if you use a different git URI for pull than push.

[bwarden]

The link-new-rpms and checkblacklist actions will also need to be modified/replaced at some point.

[bwarden]

@phmccarty, @bryteise Could I have your review, please?

[bwarden]

Remaining work, in case someone else has time to pick up the torch:

• refactor config to read autospec.conf first (so we know the git URL patterns), then go back and read package configuration files after deciding what the package name and path are.
• tackle creation of rpms subdir and hard-linking resulting RPMs. This is the last ${NAME} dependency in the common makefile.

[phmccarty]

@bryteise Is this feature still in scope for autospec?

I think it would be nice to autodetect the package name, but due to the extra complexity introduced with the interaction with the common tooling, we were somewhat undecided about what needed to change in that tooling, and autospec, or both, to accommodate...

[bryteise]

Hrm I'm a little unsure about all the bits that need to be reworked.

Because make autospecnew is probably the way an autodetected name would be made use of, getting the common tooling as much out of the way as possible of autospec doing what needs to be would be sensible. We could also we add a --get-package-name type option for autospec and then common tooling gets the name from that and reruns autospec with the full options like now under the hood.

[phmccarty]

I agree that all the name detection logic should be handled by autospec. The idea of adding a --get-package-name flag to autospec to replace the NAME value for make autospecnew also sounds reasonable...

[phmccarty]

There was also some discussion at the time about autospec creating the package Makefile (instead of the common tooling) if it doesn't exist, so that consideration could be revisited as well.

Edit: One second look, this PR adds the makefile write routine, so disregard.

Edit 2: IIRC, at the time, I wasn't convinced that autospec writing the makefile was a good idea, since the primary user of it is the common tooling, not autospec. Perhaps autospec could write a separate makefile (say, Makefile.autospec) that would be fully owned by autospec, and the common tooling could source it -- a similar approach to how it handles Makefile.custom. For non-autospec packages, Makefile would define PKG_NAME, and for autospec packages, Makefile.autospec would define it, replacing the value from Makefile if it exists there. And if autospec cannot detect, or misdetects, the package name, the common tooling could fall back to use PKG_NAME defined in Makefile (or Makefile.custom) if that's easier / makes more sense, and propagate that value to autospec like it does now.

[bwarden]

Rework to absorb a lot of the work we were doing in makefiles so that we
can avoid setting the package name manually in 'make autospecnew'.

[bwarden]

You'll also need to modify Makefile.toplevel to:

1. Remove the check for $(NAME)
2. Remove $(MAKE) clone_$(NAME) and the mkdir/git block
3. Don't write the Makefile (autospec will do that instead)
4. Remove the --target and --name parameters from autospec
5. Add the --package-dir packages/ param to autospec
6. Remove the else block for $(NAME) already exists...

...and add git_pull to autospec.conf if you use a different git URI for pull than push.

[bwarden]

The link-new-rpms and checkblacklist actions will also need to be modified/replaced at some point.

[bwarden]

@phmccarty, @bryteise Could I have your review, please?

[bwarden]

Remaining work, in case someone else has time to pick up the torch:

• refactor config to read autospec.conf first (so we know the git URL patterns), then go back and read package configuration files after deciding what the package name and path are.
• tackle creation of rpms subdir and hard-linking resulting RPMs. This is the last ${NAME} dependency in the common makefile.

[phmccarty]

@bryteise Is this feature still in scope for autospec?

I think it would be nice to autodetect the package name, but due to the extra complexity introduced with the interaction with the common tooling, we were somewhat undecided about what needed to change in that tooling, and autospec, or both, to accommodate...

[bryteise]

Hrm I'm a little unsure about all the bits that need to be reworked.

Because make autospecnew is probably the way an autodetected name would be made use of, getting the common tooling as much out of the way as possible of autospec doing what needs to be would be sensible. We could also we add a --get-package-name type option for autospec and then common tooling gets the name from that and reruns autospec with the full options like now under the hood.

[phmccarty]

I agree that all the name detection logic should be handled by autospec. The idea of adding a --get-package-name flag to autospec to replace the NAME value for make autospecnew also sounds reasonable...

[phmccarty]

There was also some discussion at the time about autospec creating the package Makefile (instead of the common tooling) if it doesn't exist, so that consideration could be revisited as well.

Edit: One second look, this PR adds the makefile write routine, so disregard.

Edit 2: IIRC, at the time, I wasn't convinced that autospec writing the makefile was a good idea, since the primary user of it is the common tooling, not autospec. Perhaps autospec could write a separate makefile (say, Makefile.autospec) that would be fully owned by autospec, and the common tooling could source it -- a similar approach to how it handles Makefile.custom. For non-autospec packages, Makefile would define PKG_NAME, and for autospec packages, Makefile.autospec would define it, replacing the value from Makefile if it exists there. And if autospec cannot detect, or misdetects, the package name, the common tooling could fall back to use PKG_NAME defined in Makefile (or Makefile.custom) if that's easier / makes more sense, and propagate that value to autospec like it does now.

[bwarden]

Rework to absorb a lot of the work we were doing in makefiles so that we
can avoid setting the package name manually in 'make autospecnew'.

[bwarden]

You'll also need to modify Makefile.toplevel to:

1. Remove the check for $(NAME)
2. Remove $(MAKE) clone_$(NAME) and the mkdir/git block
3. Don't write the Makefile (autospec will do that instead)
4. Remove the --target and --name parameters from autospec
5. Add the --package-dir packages/ param to autospec
6. Remove the else block for $(NAME) already exists...

...and add git_pull to autospec.conf if you use a different git URI for pull than push.

[bwarden]

The link-new-rpms and checkblacklist actions will also need to be modified/replaced at some point.

[bwarden]

@phmccarty, @bryteise Could I have your review, please?

[bwarden]

Remaining work, in case someone else has time to pick up the torch:

• refactor config to read autospec.conf first (so we know the git URL patterns), then go back and read package configuration files after deciding what the package name and path are.
• tackle creation of rpms subdir and hard-linking resulting RPMs. This is the last ${NAME} dependency in the common makefile.

[phmccarty]

@bryteise Is this feature still in scope for autospec?

I think it would be nice to autodetect the package name, but due to the extra complexity introduced with the interaction with the common tooling, we were somewhat undecided about what needed to change in that tooling, and autospec, or both, to accommodate...

[bryteise]

Hrm I'm a little unsure about all the bits that need to be reworked.

Because make autospecnew is probably the way an autodetected name would be made use of, getting the common tooling as much out of the way as possible of autospec doing what needs to be would be sensible. We could also we add a --get-package-name type option for autospec and then common tooling gets the name from that and reruns autospec with the full options like now under the hood.

[phmccarty]

I agree that all the name detection logic should be handled by autospec. The idea of adding a --get-package-name flag to autospec to replace the NAME value for make autospecnew also sounds reasonable...

[phmccarty]

There was also some discussion at the time about autospec creating the package Makefile (instead of the common tooling) if it doesn't exist, so that consideration could be revisited as well.

Edit: One second look, this PR adds the makefile write routine, so disregard.

Edit 2: IIRC, at the time, I wasn't convinced that autospec writing the makefile was a good idea, since the primary user of it is the common tooling, not autospec. Perhaps autospec could write a separate makefile (say, Makefile.autospec) that would be fully owned by autospec, and the common tooling could source it -- a similar approach to how it handles Makefile.custom. For non-autospec packages, Makefile would define PKG_NAME, and for autospec packages, Makefile.autospec would define it, replacing the value from Makefile if it exists there. And if autospec cannot detect, or misdetects, the package name, the common tooling could fall back to use PKG_NAME defined in Makefile (or Makefile.custom) if that's easier / makes more sense, and propagate that value to autospec like it does now.

[bwarden]

Rework to absorb a lot of the work we were doing in makefiles so that we
can avoid setting the package name manually in 'make autospecnew'.

[bwarden]

You'll also need to modify Makefile.toplevel to:

1. Remove the check for $(NAME)
2. Remove $(MAKE) clone_$(NAME) and the mkdir/git block
3. Don't write the Makefile (autospec will do that instead)
4. Remove the --target and --name parameters from autospec
5. Add the --package-dir packages/ param to autospec
6. Remove the else block for $(NAME) already exists...

...and add git_pull to autospec.conf if you use a different git URI for pull than push.

[bwarden]

The link-new-rpms and checkblacklist actions will also need to be modified/replaced at some point.

[bwarden]

@phmccarty, @bryteise Could I have your review, please?

[bwarden]

Remaining work, in case someone else has time to pick up the torch:

• refactor config to read autospec.conf first (so we know the git URL patterns), then go back and read package configuration files after deciding what the package name and path are.
• tackle creation of rpms subdir and hard-linking resulting RPMs. This is the last ${NAME} dependency in the common makefile.

[phmccarty]

@bryteise Is this feature still in scope for autospec?

I think it would be nice to autodetect the package name, but due to the extra complexity introduced with the interaction with the common tooling, we were somewhat undecided about what needed to change in that tooling, and autospec, or both, to accommodate...

[bryteise]

Hrm I'm a little unsure about all the bits that need to be reworked.

Because make autospecnew is probably the way an autodetected name would be made use of, getting the common tooling as much out of the way as possible of autospec doing what needs to be would be sensible. We could also we add a --get-package-name type option for autospec and then common tooling gets the name from that and reruns autospec with the full options like now under the hood.

[phmccarty]

I agree that all the name detection logic should be handled by autospec. The idea of adding a --get-package-name flag to autospec to replace the NAME value for make autospecnew also sounds reasonable...

[phmccarty]

There was also some discussion at the time about autospec creating the package Makefile (instead of the common tooling) if it doesn't exist, so that consideration could be revisited as well.

Edit: One second look, this PR adds the makefile write routine, so disregard.

Edit 2: IIRC, at the time, I wasn't convinced that autospec writing the makefile was a good idea, since the primary user of it is the common tooling, not autospec. Perhaps autospec could write a separate makefile (say, Makefile.autospec) that would be fully owned by autospec, and the common tooling could source it -- a similar approach to how it handles Makefile.custom. For non-autospec packages, Makefile would define PKG_NAME, and for autospec packages, Makefile.autospec would define it, replacing the value from Makefile if it exists there. And if autospec cannot detect, or misdetects, the package name, the common tooling could fall back to use PKG_NAME defined in Makefile (or Makefile.custom) if that's easier / makes more sense, and propagate that value to autospec like it does now.

[bwarden]

Rework to absorb a lot of the work we were doing in makefiles so that we
can avoid setting the package name manually in 'make autospecnew'.

[bwarden]

You'll also need to modify Makefile.toplevel to:

1. Remove the check for $(NAME)
2. Remove $(MAKE) clone_$(NAME) and the mkdir/git block
3. Don't write the Makefile (autospec will do that instead)
4. Remove the --target and --name parameters from autospec
5. Add the --package-dir packages/ param to autospec
6. Remove the else block for $(NAME) already exists...

...and add git_pull to autospec.conf if you use a different git URI for pull than push.

[bwarden]

The link-new-rpms and checkblacklist actions will also need to be modified/replaced at some point.

[bwarden]

@phmccarty, @bryteise Could I have your review, please?

[bwarden]

Remaining work, in case someone else has time to pick up the torch:

• refactor config to read autospec.conf first (so we know the git URL patterns), then go back and read package configuration files after deciding what the package name and path are.
• tackle creation of rpms subdir and hard-linking resulting RPMs. This is the last ${NAME} dependency in the common makefile.

[phmccarty]

@bryteise Is this feature still in scope for autospec?

I think it would be nice to autodetect the package name, but due to the extra complexity introduced with the interaction with the common tooling, we were somewhat undecided about what needed to change in that tooling, and autospec, or both, to accommodate...

[bryteise]

Hrm I'm a little unsure about all the bits that need to be reworked.

Because make autospecnew is probably the way an autodetected name would be made use of, getting the common tooling as much out of the way as possible of autospec doing what needs to be would be sensible. We could also we add a --get-package-name type option for autospec and then common tooling gets the name from that and reruns autospec with the full options like now under the hood.

[phmccarty]

I agree that all the name detection logic should be handled by autospec. The idea of adding a --get-package-name flag to autospec to replace the NAME value for make autospecnew also sounds reasonable...

[phmccarty]

There was also some discussion at the time about autospec creating the package Makefile (instead of the common tooling) if it doesn't exist, so that consideration could be revisited as well.

Edit: One second look, this PR adds the makefile write routine, so disregard.

Edit 2: IIRC, at the time, I wasn't convinced that autospec writing the makefile was a good idea, since the primary user of it is the common tooling, not autospec. Perhaps autospec could write a separate makefile (say, Makefile.autospec) that would be fully owned by autospec, and the common tooling could source it -- a similar approach to how it handles Makefile.custom. For non-autospec packages, Makefile would define PKG_NAME, and for autospec packages, Makefile.autospec would define it, replacing the value from Makefile if it exists there. And if autospec cannot detect, or misdetects, the package name, the common tooling could fall back to use PKG_NAME defined in Makefile (or Makefile.custom) if that's easier / makes more sense, and propagate that value to autospec like it does now.