[pacman-dev] [PATCH] repo-add: fix db creation one last time
We fubar-ed this pretty good.
1. The whole old/new move shuffle was totally busted if you used a
relative path to your database, as we would just build the database in
place.
2. Our prior temp directory layout had the database files extracted
directly into it. When we tried to create a xxx.db.tar.gz file in this
same directory, due to the fact that we were no longer using a shell
wildcard, we tried to include the db in ourself, which is a big failure.
Fix all this by extracting to tree/ so we can have a clean top-level
temp directory.
3. Fix the inclusion of the './' directory entry; ensure the regex
prunes both leading paths of '.' as well as './'.
Where is that test suite again?
Signed-off-by: Dan McGee
On 29/06/11 10:58, Dan McGee wrote:
We fubar-ed this pretty good.
1. The whole old/new move shuffle was totally busted if you used a relative path to your database, as we would just build the database in place. 2. Our prior temp directory layout had the database files extracted directly into it. When we tried to create a xxx.db.tar.gz file in this same directory, due to the fact that we were no longer using a shell wildcard, we tried to include the db in ourself, which is a big failure. Fix all this by extracting to tree/ so we can have a clean top-level temp directory. 3. Fix the inclusion of the './' directory entry; ensure the regex prunes both leading paths of '.' as well as './'.
Where is that test suite again?
Signed-off-by: Dan McGee
Signed-off-by: Allan Updating my repo without this patch resulted in fun!
On Thu, Jun 30, 2011 at 01:01:35PM +1000, Allan McRae wrote:
On 29/06/11 10:58, Dan McGee wrote:
We fubar-ed this pretty good.
1. The whole old/new move shuffle was totally busted if you used a relative path to your database, as we would just build the database in place. 2. Our prior temp directory layout had the database files extracted directly into it. When we tried to create a xxx.db.tar.gz file in this same directory, due to the fact that we were no longer using a shell wildcard, we tried to include the db in ourself, which is a big failure. Fix all this by extracting to tree/ so we can have a clean top-level temp directory. 3. Fix the inclusion of the './' directory entry; ensure the regex prunes both leading paths of '.' as well as './'.
Where is that test suite again?
Signed-off-by: Dan McGee
Signed-off-by: Allan
Updating my repo without this patch resulted in fun!
I think we axed this as well. The tarball gets all out of order (directories first), so we're going to go with my original patch that Dan Nack'ed, which was to use "ugly" bash... (shopt -s nullgob; files=(*); ((${#files[*]}))) almost lispy... d
On Wed, Jun 29, 2011 at 10:06 PM, Dave Reisner
On Thu, Jun 30, 2011 at 01:01:35PM +1000, Allan McRae wrote:
On 29/06/11 10:58, Dan McGee wrote:
We fubar-ed this pretty good.
1. The whole old/new move shuffle was totally busted if you used a relative path to your database, as we would just build the database in place. 2. Our prior temp directory layout had the database files extracted directly into it. When we tried to create a xxx.db.tar.gz file in this same directory, due to the fact that we were no longer using a shell wildcard, we tried to include the db in ourself, which is a big failure. Fix all this by extracting to tree/ so we can have a clean top-level temp directory. 3. Fix the inclusion of the './' directory entry; ensure the regex prunes both leading paths of '.' as well as './'.
Where is that test suite again?
Signed-off-by: Dan McGee
Signed-off-by: Allan
Updating my repo without this patch resulted in fun!
I think we axed this as well. The tarball gets all out of order (directories first), so we're going to go with my original patch that Dan Nack'ed, which was to use "ugly" bash...
(shopt -s nullgob; files=(*); ((${#files[*]})))
almost lispy...
No, we axed just the bsdtar bit, not the rest of it. Creating a tar file in the same directory as the files you are archiving is not really a good idea ever, even if some crappy shell expansion avoids it. It clearly burned us once, so I'm not having it burn us again. -Dan
On Wed, Jun 29, 2011 at 10:15:12PM -0500, Dan McGee wrote:
On Wed, Jun 29, 2011 at 10:06 PM, Dave Reisner
wrote: On Thu, Jun 30, 2011 at 01:01:35PM +1000, Allan McRae wrote:
On 29/06/11 10:58, Dan McGee wrote:
We fubar-ed this pretty good.
1. The whole old/new move shuffle was totally busted if you used a relative path to your database, as we would just build the database in place. 2. Our prior temp directory layout had the database files extracted directly into it. When we tried to create a xxx.db.tar.gz file in this same directory, due to the fact that we were no longer using a shell wildcard, we tried to include the db in ourself, which is a big failure. Fix all this by extracting to tree/ so we can have a clean top-level temp directory. 3. Fix the inclusion of the './' directory entry; ensure the regex prunes both leading paths of '.' as well as './'.
Where is that test suite again?
Signed-off-by: Dan McGee
Signed-off-by: Allan
Updating my repo without this patch resulted in fun!
I think we axed this as well. The tarball gets all out of order (directories first), so we're going to go with my original patch that Dan Nack'ed, which was to use "ugly" bash...
(shopt -s nullgob; files=(*); ((${#files[*]})))
almost lispy...
No, we axed just the bsdtar bit, not the rest of it. Creating a tar file in the same directory as the files you are archiving is not really a good idea ever, even if some crappy shell expansion avoids it. It clearly burned us once, so I'm not having it burn us again.
-Dan
Oh yeah. We did discuss this. So, ignore the patch I just sent. I've got the right one somewhere... d
On Wed, Jun 29, 2011 at 10:26 PM, Dave Reisner
On Wed, Jun 29, 2011 at 10:15:12PM -0500, Dan McGee wrote:
On Wed, Jun 29, 2011 at 10:06 PM, Dave Reisner
wrote: On Thu, Jun 30, 2011 at 01:01:35PM +1000, Allan McRae wrote:
On 29/06/11 10:58, Dan McGee wrote:
We fubar-ed this pretty good.
1. The whole old/new move shuffle was totally busted if you used a relative path to your database, as we would just build the database in place. 2. Our prior temp directory layout had the database files extracted directly into it. When we tried to create a xxx.db.tar.gz file in this same directory, due to the fact that we were no longer using a shell wildcard, we tried to include the db in ourself, which is a big failure. Fix all this by extracting to tree/ so we can have a clean top-level temp directory. 3. Fix the inclusion of the './' directory entry; ensure the regex prunes both leading paths of '.' as well as './'.
Where is that test suite again?
Signed-off-by: Dan McGee
Signed-off-by: Allan
Updating my repo without this patch resulted in fun!
I think we axed this as well. The tarball gets all out of order (directories first), so we're going to go with my original patch that Dan Nack'ed, which was to use "ugly" bash...
(shopt -s nullgob; files=(*); ((${#files[*]})))
almost lispy...
No, we axed just the bsdtar bit, not the rest of it. Creating a tar file in the same directory as the files you are archiving is not really a good idea ever, even if some crappy shell expansion avoids it. It clearly burned us once, so I'm not having it burn us again.
-Dan
Oh yeah. We did discuss this. So, ignore the patch I just sent. I've got the right one somewhere...
I should be able to mash them together in the right fashion. -Dan
Revert to the old behavior that 6f5a90 attempted to simplify and go with
the original proposed solution of using "ugly" bash to detect empty
directories.
Signed-off-by: Dave Reisner
participants (4)
-
Allan McRae
-
Dan McGee
-
Dan McGee
-
Dave Reisner